@extends('template') @section('content')
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, 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.
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!
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.
metadata.txt.gpg --import ./openrsc-gpg-public-key-2023-02-16.keygpg --list-keys to see the user-id of the imported key. Currently it is 422EF5A2134ED3DCCE5D48522E3225A88AD92DF1gpg --edit-key 422EF5A2134ED3DCCE5D48522E3225A88AD92DF1trust" to enter an interactive mode where you set the trust level.gpg --update-trustdbgpg --output ./data.zip --decrypt ./data.zip.gpggpg: 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.txtThis file contains important information for adminstrators considering importing a player.
Here is an example metadata.txt file:
Server: cabbage
Timestamp: 1678813071348
Muted: 0
Banned: 0
Offences: 0
GPG Link: https://rsc.vet/openrsc-gpg-public-key-2023-02-16.key
GPG Archive Link: https://web.archive.org/web/20230224020441/https://rsc.vet/openrsc-gpg-public-key-2023-02-16.key
playerdata.dbAs 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.sqlThis 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