How to use Open RSC player exports!

To export

Player accounts may be exported from https://rsc.vet/playerexport. You will need to know the username and password for the account being exported. Banned accounts may be exported as well.

The page looks like this:

For single-player, or with your friends

For single-player, you will want to use the playerdata.db file. This is a fully contained sqlite database file compatible with the Open RSC server. Information on how to run an Open RSC server is not covered here, but suffice to say that once the server is pointed correctly at this file, and your client is pointed correctly at your server, you will be able to log in to your account as normal, with all account data intact. If you were banned or muted previously, you are unbanned and unmuted in your player export.

For a locally hosted server with multiple characters, you will need to merge the player exports together by importing multiple player's exports playerdata.sql files into a single database. The SQL inside those files is compatible with both MariaDB and SQLite. I recommend using the program HeidiSQL for manipulating SQL databases.

For import into a foreign server

Disclaimer

The data.zip.gpg file is not necessary to use unless you are a server administrator importing data from lots of people you do not necessarily trust. If you are not a foreign server administrator, you should still keep this file in case you might ever want to give it to someone who is one!

Introduction

Open RSC player exports include a GPG signed zip archive of the metadata.txt, playerdata.db, and playerdata.sql files, in a file which is always called data.zip.gpg

By using GPG, you can verify that the account data has not been altered since it was exported from Open RSC.

How to extract

1. First, you will need the public key associated with the private key that Open RSC used to sign the data. A link to this file is included in metadata.txt.
2. Ensure that you trust the GPG Link looks like it belongs to Open RSC. We have used https://rsc.vet and https://openrsc.com at the time of this writing.
3. Download the key.
4. On a linux system, the command used to import a gpg public key is: gpg --import ./openrsc-gpg-public-key-2023-02-16.key
5. You will want to inform GPG how much you trust that data signed with the private key associated with that public key comes from Open RSC.
6. Use gpg --list-keys to see the user-id of the imported key. Currently it is 422EF5A2134ED3DCCE5D48522E3225A88AD92DF1
7. Replacing the user-id with whatever is most current, use gpg --edit-key 422EF5A2134ED3DCCE5D48522E3225A88AD92DF1
8. Type the command "trust" to enter an interactive mode where you set the trust level.
9. Choose how much you trust the key. Ultimate trust or Fully trust are suggested.
10. Use gpg --update-trustdb
11. Finally, extract the data with gpg --output ./data.zip --decrypt ./data.zip.gpg
12. If the player export is legitimately from Open RSC, you will receive the message "gpg: Good signature from "Open RSC (Email address on this GPG key will probably not work for contacting us. Our admins' individual email addresses should be on git commits by Ken, Kenix, Logg, Luis, Marwolf or Ryan. If Discord still exists when you're reading this message, that's the best way to reach us, as of 2023-02-16!) " [ultimate]" as part of the extraction output.

metadata.txt

This file contains important information for adminstrators considering importing a player.

Here is an example metadata.txt file:

• Server
• You would want to verify that the Server is the intended server you wish to import.
• Timestamp
• This is a Unix timestamp with milliseconds. This will be important to verify if you would not like to accept very old exports, or when comparing two user's export times, you may not want to import both players' items to your server, since one player could have given their items to another player after exporting their account. Importing both players would be a "duplication bug" on your server. However, if the timestamp is after a hypothetical closing of Open RSC, or near to it, you would be able to accept both untrusted player's items without issue.
• Muted / Banned
• For player exports, we wipe the Muted and Banned fields, but preserve their original values in this file. This is useful for troublemakers who have been banned, since they will not need to figure out how to unban themselves in order to play single-player, but as a server administrator, it may be wise to verify that a user banned on Open RSC will not be a problem for you on your server (e.g., they might have lots of wealth on their account from a historic duping bug).
• Offences
• This field may contain information about the mute/ban. Currently, the number increments each time an "offense" is committed (see the openrsc core source code to see what that means), but sometimes the Offences number might be used to catalogue a specific type of offense. I used value 10 for players who were caught duping in early 2023, for example.
• GPG Link / GPG Archive Link
• We include this so that when extracting the data.zip.gpg file, you have a link to the public key needed to verify the signature. We also include the archive link, in case https://rsc.vet is no longer accessible.

playerdata.db

As a foreign server administrator, you do not need this file. It is a SQLite database containing just the one user's data, intended for that player to use with a single-player server.

playerdata.sql

This file contains several INSERT statements with all of the user's data. You should be run this file without issue, importing to MariaDB or SQLite.

If you are importing into a server with existing users, not from Open RSC, you will need to manually figure out how to change the id field of player in the player table, and then also update their player id for all the associated database tables. If the player id is not adjusted to be compatible with your server, you will encounter collisions between users by importing playerdata.sql without modification.

If you haven't already started allowing new user registrations on your server, it would be sane to insert an entry into the players table with a high id, something like 100,000,000, so that AUTO_INCREMENT for new player ids will safely avoid the space where original Open RSC accounts were created (currently we are up to player IDs around 20,000 on the RSC Preservation server)

We trust you are able to handle this.

Thanks on behalf of the entire Open RSC Team,

— Logg