Setting Up a Shard

Revision as of 16:05, 2 August 2011 by Diafero (Talk | contribs) (Preparation: typo)

This tutorial documents the smallest possible setup for a Shard. It is intended to be used on a "normal" PC, to develop ages or the actual server and client software. You can however easily build a "production-style" Shard on top of this.

Preparation

You will need both a Windows machine for the client, and a Linux machine for the server. It is possible to do it all on one PC using a virtual machine and possibly Wine, but the exact details of such a setup are beyond the scope of this tutorial.

On your Windows box, you need to

  • Compile the latest version of the GoW fork of the CyanWorlds.com Engine (CWE)
    • Make sure you are creating an internal build (which is the default). You can select that in CMake, "PLASMA_EXTERNAL_RELEASE" must be set to "OFF".
    • After starting VisualStudio for the first time, you can choose the build type at the top of the main windows, in a drop-down menu: "Debug" or "Release" (or some other, rarely used options). I suggest to use "Release" there (Debug builds currently show assertion failure error messages on startup).
  • Install the and download Myst Online: Uru live again (MOULa)
  • Download the Python and SDL files

On the Linux machine

Server setup

The DirtSand server is not yet quite ready, we need to give it some final touches

Encryption keys

The connection between the server and the client is always encrypted. To make this work, you need to generate the necessary keys. Don't worry, DirtSand has it all built in (the paths assume that you installed DirtSand into ~/dirtsand, which is what the installation tutorial does):

cd ~/dirtsand
bin/dirtsand dirtsand.ini # start the server, another prompt will open
ds-902> keygen new # This may take some time and will generate some random series of characters
ds-902> quit # quit the server, go back to the shell

After the "keygen" command, two blocks of text have been printed. The first block goes into the dirtsand.ini file of the server, just copy-and-paste it there (copy only the lines starting with "Key"!). The second part is necessary for the client to connect to the server, save it to some file called "server.ini" that you send to the Windows machine (again, only the lines starting with "Server" must be copied).

Remaining configuration

The dirtsand.ini file needs one final touch: The IP addresses and paths to the files need to be changed to your setup. I assume that the full path to the DirtSand directory is "/home/user/dirtsand", usually you will just have to insert your username. If in doubt, run

echo $HOME/dirtsand

To find out the address of your machine, you can use the command "sudo ifconfig". Look for the line saying "inet addr" (if it's "127.0.0.1", you looked at the wrong interface). Be sure to have some kind of firewall between you and the internet!

Now open dirtsand.ini, and insert your IP address behind "File.Host", "Auth.Host" and "Game.Host". You will also need to edit the "Paths" section, this tutorial assumes it looks as follows:

File.Root = /home/user/dirtsand/data
Auth.Root = /home/user/dirtsand/authdata
Sdl.Path = /home/user/dirtsand/SDL
Age.Path = /home/user/dirtsand/ages

To properly host the ages, the Shard needs to know which ages are available. That's why you downloaded the SDL and age files at the beginning (just delete the Python folder in there, you only need it on the client machine). Copy the remaining two folders "SDL" and "dat" to the DirtSand directory, and rename "dat" to "ages". These are exactly the folders you just set for "Sdl.Path" and "Age.Path".

Dataserver

To complete the server, we need a minimalistic dataserver. We do not have to actually put any data on it, so that you can still put whatever you want into the client folder, but the client will still request some data and we must tell the server that there's nothing to reply with. The following command will create a bunch of empty files to achieve exactly that:

cd ~/dirtsand
mkdir data authdata
touch data/Internal.mfs data/InternalPatcher.mfs data/ThinInternal.mfs authdata/Python_pak.list authdata/SDL_sdl.list

That's it, the little fake dataserver is complete! It is now your responsibility to make sure all the clients (if more than one person connects to the Shard) use the same dataset.

Client setup

On the client side we now need to copy all the files together that are necessary for Uru to run. Start with an empty folder (I will refer to it as "CWE").

  1. Extract the Python and SDL files into it. You can remove the dat folder that was created alongside.
  2. Copy the dat, sfx and avi folders and the files "OpenAL32.dll" and "wrap_oal.dll" from your MOULa client to the CWE folder.
  3. From the PhysX SDK, copy the files Nx*.dll and PhysXLoader.dll to the CWE folder - on a default setup, you can find these files at "C:\Program Files\AGEIA Technologies\AGEIA PhysX SDK\v2.6.4\Bin\win32".
  4. From the CWE build directory, copy the launcher and the actual client:
    • If you created a Debug build, these files are at ".../build/Sources/Plasma/Apps/plClient/Debug/plClient.exe" and ".../build/Sources/Plasma/Apps/plUruLauncher/Debug/plUruLauncher.exe" (where ".../build" is the build directory you chose in CMake during CWE compilation). In the CWE folder, you have to rename plUruLauncher.exe to UruLauncher.exe and plClient.exe to plClient_dbg.exe.
    • If you created a Release build, these files are at ".../build/Sources/Plasma/Apps/plClient/Release/plClient.exe" and ".../build/Sources/Plasma/Apps/plUruLauncher/Release/plUruLauncher.exe" (where ".../build" is the build directory you chose in CMake during CWE compilation). In the CWE folder, you have to rename plUruLauncher.exe to UruLauncher.exe (plClient.exe does not have to be renamed).

<incomplete>