Storage Locations

Note: Location of The Server Itself is Not Discussed Here.

The Server binary should be distributed alongside or as part of the Front-End [(Launcher)][launcher].
An outdated Server binary will simply self-update, no worries.

Example Problem.

You are at a LAN party or an Office Space. You want to quickly start playing modded online with your friends but the machine you're at is not the machine you used the last time.

Another person last using the machine has previously downloaded the mods.
You shouldn't need to download and store them on disk again.

Achieving these advanced use cases requires some careful planning.

For example Mod(s) themselves could be stored in a location that's shared between all users on a machine, provided they don't store any user specific data, for example mod settings.

Scoped Storage System

Data stored by Reloaded3 is categorised into the following categories.

• Machine (Persistent): Machine specific data that cannot be regenerated.
  • Should not be deleted by user manually.
  • For example, Game Backups.
• Machine (Cache): Machine specific data that can be regenerated.
  • These items can be safely deleted when not used.
  • For example, Downloaded packages (Mods, Tools etc.)
  • Items that can always be restored with Package Metadata.
• User: User specific data.
  • Settings, loadouts, configurations etc.

Where are the Files Stored?

• Machine (Persistent):

  • Windows: C:\ProgramData\Reloaded3\Main (a.k.a. $CommonApplicationData+Main)
  • macOS: /Library/Application Support/Reloaded3
  • Linux: /var/lib/Reloaded3 ([Filesystem Hierarchy Standard Info][var-lib])

• Machine (Cache):

  • Windows: C:\ProgramData\Reloaded3\Cache (a.k.a. $CommonApplicationData+Cache)
  • macOS: /Library/Caches/Reloaded3
  • Linux: /var/cache/Reloaded3 ([Filesystem Hierarchy Standard Info][var-cache])

• User:

  • Windows: C:\Users\{User}\AppData\Roaming\Reloaded3 (a.k.a. ApplicationData)
  • macOS: ~/Library/Application Support/Reloaded3
  • Linux: ~/.local/share/Reloaded3 (a.k.a. XDG_DATA_HOME)

Portable Install

About Portable Installs

Some users will (very strongly) insist that they want to run Reloaded3 in a 'portable' way.

Sometimes it's personal preference, sometimes it's a more niche use case like running a modded game on a USB stick.

Portable Use is Discouraged

Unless the game you're modding is itself portable, i.e. on a USB stick, use of portable mode should be discouraged.

The Server & Loader will recognise the following condition as 'portable':

A folder named .Reloaded3 exists in the same folder as the game and Server binary.

In this case the following locations should be used.

• Machine (Persistent): .Reloaded3/Main
• Machine (Cache): .Reloaded3/Cache
• User: .Reloaded3/User

For Tools downloaded via the R3 package manager, they should assume portable mode if .Reloaded3 is part of the path to the main binary.

Items to Store

What do we want to store and where do we store it?

Item	Scope	Subfolder	Description
Temporary Files (Mods)	Machine (Persistent)[1]	Temp/{processId}	Temporary files generated by mods at runtime. Not persisted across runs.
Package Cache Files (Machine)	Machine (Persistent)	Cache/Package/{packageId}	Cache files that consist of inputs that don't include user data.
Package Cache Files (User)	User	Cache/Package/{packageId}	Cache files that have inputs with user data.
Server Cache Files	Machine (Persistent)	Cache/Server	Cache files tied to the Reloaded3 server.
Packages (Mods, Tools, etc.)	Machine (Cache)	Packages	Pretty much anything you can download.
Loadouts	User	Loadouts	Loadouts that are private to the current user.
Loadouts (Shared)	Machine (Persistent)	Loadouts	Loadouts that are shared between all users.
Package Configs (Machine)	Machine (Persistent)	PackageConfigs/{packageId}	Config/Save files for packages.
Package Configs (User)	User	PackageConfigs/{packageId}	Config/Save files for packages. This contains user data.
Added Games	User	Games/{gameId}	And all of user's global preferences for that game.

[1] Temporary Files should be tied to ProcessID, if a process with that ID is dead, they should be auto deleted by the server. To avoid files in use accidentally being deleted, temporary files are stored in persistent storage. We will auto clean them ourselves.

Cache Files

Cache format is specific to the package/implementation.

Each package gets its own cache folder. The package itself is responsible it can handle errors with the cache, such as a version/format upgrade.

Note the presence of a Cache folder with and without user data.

Server Cache Files

These are cache files tied to the Reloaded3 server.

It has the following structure:

CommunityRepository

Community Repository

This contains a local cache of the Community Repository

This folder consists of a file named etag.txt and a copy of the Nx packed CommunityRepository.nx.

The ETag will be used to determine if the local cached archive is outdated.

If it is, we will download the new CommunityRepository.nx, else we'll use the local cache.

Loadouts

The file format of the actual loadouts is defined in the Loadouts page.

Loadouts are stored in the Loadouts folder.

Each loadout is stored in an .nx archive, names {UID}.nx where {UID} is a randomly generated 64-bit integer.

When a loadout is loaded, it gets extracted to a folder named {UID} in the same folder as the .nx, and the orignal .nx file is deleted.

The format of the extracted folder is documented under Loadout File Format.

About Multi User Networked Systems

On Windows, files in AppData/Roaming are usually downloaded upon login in multi-user setup configurations, and this download typically happens on every login.

On the other hand, on Linux systems, it's much more likely that the Home Directory is accessed over the network in real-time, resulting in no wait time at the expense of high latency. Likely with some sort of caching mechanism in place.

Taking these factors into account, we should aim to keep the user data as small as possible, and ensure we don't unnecessarily access too many small files. Parralelise file access if possible to reduce the impact of high latency.