The Launcher

What It Does

The launcher is what a player runs instead of the game executable. It:

1. asks your server whether it is up, and what version it is running,
2. checks your server for updated client files and fetches what changed,
3. takes an email and password and gets an account from the server,
4. hands the client its login state and starts it.

The update check comes before the login on purpose. If it cannot confirm the client is current it stops there, and somebody who is going to be stopped should be stopped before they type a password.

It holds no database credentials and no local account list. If it says the server is offline, that is because your server did not answer, and there is nothing else it could have asked.

Where It Lives

In the player’s own game folder, beside the game executable. It ships in the client/ directory of every release, and “copy the contents of client/ into your game folder” is the whole install.

launcher.ini

Written beside the launcher on first run, with sensible defaults. A player only edits it to point at a different server.

[Server]
Host         = your-server.example.com
GamePort     = 27800
AuthPort     = 27801

[Client]
ClientDir    =
ClientBinary = RF_Online.bin

[Credentials]
Remember     = false
Email        =
Password     =

[Update]
URL          = https://your-server.example.com

ClientDir empty means the folder the launcher is sitting in, which is the normal case. AuthPort is the game port plus one and there is no reason to change it on its own.

A remembered password is obfuscated rather than encrypted. That stops it sitting in plain sight in a file someone might screenshot or paste into a bug report, and it is not claimed to be more than that.

Keeping Client Files Current

This is the [Update] URL key, and it is empty by default, which means the launcher never checks. Point it at your website and the launcher patches before every start, and will not start the game until it has confirmed the client is current.

The mechanism is deliberately plain. Your website serves the client/ directory at /downloads/client/, with an index of file hashes at /downloads/client/manifest.txt. The launcher hashes the copies it has, downloads only what differs, and re-hashes what it wrote before starting the game. There are no version numbers, no patch files, and no state on your server beyond a directory.

To push a client change out:

1. Drop the files into client/.

2. Regenerate the index:

   tools/manifgen client -o client/manifest.txt -exclude "rflauncher.exe,launcher.ini,DefaultSet.tmp"

3. Nothing else. Every launcher picks it up on its next run.

Three Files Are Never Overwritten

rflauncher.exe, launcher.ini and the login handoff file are protected, and the launcher refuses to replace them no matter what a manifest says. Two are the player’s own state, and the third is written seconds after the update finishes. The -exclude above keeps them out of the index; the launcher’s refusal is what covers a stale index, a mistake in a future release, or a manifest that did not come from you.

The launcher does not update itself. It carries its own version number, so its hash changes on every release, and a hash-compare update would re-download it every time for no reason. It ships in client/ and a player replaces it by copying a new one over.

What Happens When It Cannot Reach You

The game does not start.

Once [Update] URL is set, confirming the client is current is the launcher’s job, and a launcher that cannot do its job does not hand the client to the player. It says which of the two things went wrong, because they need different answers from you:

• It could not reach your update server. Nothing was checked. The player is told to check their connection and retry, and the launcher offers a Retry button rather than making them start over.
• It reached your server and a file would not apply. Something answered, and what came back could not be written or did not match the hash you published. That one is worth a reinstall if it keeps happening.

This is deliberate and it is a change from earlier versions, which verified against the manifest already on disk and started the game anyway. A client running stale data against a live server does not fail quietly: it disagrees with you about item tables or map data and produces bug reports that describe your last release. Neither the player nor you can tell that apart from a real bug.

The practical consequence for you is that your patch server is now part of your service. If it is down, nobody plays. Serving /downloads/client/ from the same host as the website leaves you one thing to keep up rather than two.

If you have not set [Update] URL at all, none of this applies and nothing changed: a launcher with no update server configured has nothing to confirm and starts the game the way it always did.

Running It from a Script

rflauncher.exe -status                                   # is the server up, and on what version
rflauncher.exe -update                                   # patch the client, do not log in or launch
rflauncher.exe -email [email protected] -password secret   # log in and start, no window

No window opens for any of these, which is what makes them useful for testing and for a headless check that your patch server is serving what you think it is.

-update exits non-zero if it could not reach your server, including when it fell back to the manifest already in the client folder. That fallback is why it is worth running deliberately: a client that has been patched before has a manifest on disk, so “nothing to do” and “I could not ask” look identical from the outside unless the command tells you which one it was.