Difference between revisions of "Setting Up a Shard"

m (Preparation: typo)
m (Client setup)
 
(13 intermediate revisions by 5 users not shown)
Line 1: Line 1:
 
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.
 
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=
+
== 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 [http://www.winehq.org Wine], but the exact details of such a setup are beyond the scope of this tutorial.
 
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 [http://www.winehq.org Wine], but the exact details of such a setup are beyond the scope of this tutorial.
Line 8: Line 8:
 
* Compile the latest version of the GoW fork of the [[Development:CyanWorlds.com Engine|CyanWorlds.com Engine]] (CWE)
 
* Compile the latest version of the GoW fork of the [[Development:CyanWorlds.com Engine|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".
 
** 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).
+
** After starting VisualStudio for the first time, you can choose the build type at the top of the main window, 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 [http://www.mystonline.com/ Myst Online: Uru live again] (MOULa)
 
* Install the and download [http://www.mystonline.com/ Myst Online: Uru live again] (MOULa)
* Download the [https://github.com/H-uru/moul-scripts/tree/python27 Python and SDL files]
+
* Download the [https://github.com/H-uru/moul-scripts Python and SDL files]
  
 
On the Linux machine
 
On the Linux machine
* Set up the [[Development:DirtSand|DirtSand]] server
+
* Set up the [[Development:DIRTSAND|DIRTSAND]] server
* Download the [https://github.com/H-uru/moul-scripts/tree/python27 SDL and age files] (yeah, both machines need these)
+
  
=Server setup=
+
== Server setup ==
  
The DirtSand server is not yet quite ready, we need to give it some final touches
+
The DirtSand server is not yet quite ready, we need to give it some final touches.
  
==Encryption keys==
+
=== IP address ===
  
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):
+
DirtSand also needs the IP address of the server it is running on. 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!
<source lang="bash">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</source>
+
  
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).
+
Now open dirtsand.ini, and insert your IP address behind "File.Host", "Auth.Host" and "Game.Host".
  
==Remaining configuration==
+
=== Dataserver ===
  
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
+
To complete the server, we need a minimalistic dataserver. First tell DirtSand where we are going to put it. In the "Paths" section of dirtsand.ini, change the following options (again replacing "<user>" by your username, and assume you used the default setup suggested by the DirtSand introduction):
<source lang="bash">echo $HOME/dirtsand</source>
+
File.Root = /home/<user>/dirtsand/data
 +
Auth.Root = /home/<user>/dirtsand/data
  
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!
+
We do not want to actually put any data on the dataserver so that you can still put whatever you want into the client folder. However, 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:
 
+
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:
+
 
<source lang="bash">cd ~/dirtsand
 
<source lang="bash">cd ~/dirtsand
 
mkdir data authdata
 
mkdir data authdata
Line 53: Line 37:
 
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.
 
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=
+
=== Server startup ===
 +
 
 +
You are now ready to start the server and let it wait for a client to connect to:
 +
<source lang="bash">bin/dirtsand dirtsand.ini
 +
ds-902> addacct username password</source>
 +
The addacct command creates an account on the server that you can use to log in with the client.
 +
 
 +
== 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").
 
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").
Line 60: Line 51:
 
# Copy the dat, sfx and avi folders and the files "OpenAL32.dll" and "wrap_oal.dll" from your MOULa client to the CWE folder.
 
# Copy the dat, sfx and avi folders and the files "OpenAL32.dll" and "wrap_oal.dll" from your MOULa client to the CWE folder.
 
# 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".
 
# 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".
# From the CWE build directory, copy the launcher and the actual client:
+
# If this is not the machine that you compiled CWE on (or if you want to install it on a second computer), download and install the [http://www.nvidia.com/object/physx-9.10.0513-driver.html PhsyX System Software].
#* 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.
+
# From the "dll" directory of the devlib.zip file, copy python27.dll if you created a Release build, or python27_d.dll if you created a Debug build.
#* 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).
+
# From the CWE build directory, copy the client (".../build" refers to the build directory you chose in CMake during CWE compilation)
<incomplete>
+
#* If you created a Debug build, that file is at ".../build/Sources/Plasma/Apps/plClient/Debug/plClient.exe".
 +
#* If you created a Release build, that file is at ".../build/Sources/Plasma/Apps/plClient/Release/plClient.exe".
 +
# Download the [https://www.guildofwriters.org/tools/resource.dat resource.dat] file and put it into the CWE folder as well (it contains cursors and images for the client).
 +
 
 +
Now the client just needs to be configured. Create an empty filed called "server.ini" with only two lines, telling Uru where to connect to your server:
 +
Server.Gate.Host "123.45.67.89"
 +
Server.Auth.Host "123.45.67.89"
 +
Of course you need to replace the IP address with the one you also used for the dirtsand.ini configuration file.
 +
 
 +
Now the client is ready, however it needs to be started with additional command-line parameters to work without a proper dataserver. The easiest way to achieve that is to create a shortcut to plClient.exe into your desktop, then right-click and edit it ("Properties"). Select the "Target" field, and add " -LocalData" to it's end. Make sure there is a space between "plClient.exe" and the parameter!
 +
 
 +
Now you are ready to double-click the shortcut, enter the credentials you choose (when you typed the "addacct" command), and log in to your own, private Shard!
 +
 
 +
== Limitations ==
 +
 
 +
There are two fundamental limitations to this Shard, which is why you should not use it for anything but testing:
 +
* No dataserver: Uru assumes every client to have exactly the same set of files, which is usually ensured by a dataserver. This setup lacks such an auto-update mechanism, to make it easier for you to test new ages. This however means that the sychronization has to be done manually, which of course only works for very controlled environments.
 +
* No encryption: To make the setup easier, the connection between client and server is not encrypted. This allow replay-attacks to log in to another user's account if you can sniff their network connection. A production-style server should use encryption. See the README file shipped with DirtSand for how to do that.

Latest revision as of 20:39, 8 February 2016

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 window, 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.

IP address

DirtSand also needs the IP address of the server it is running on. 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".

Dataserver

To complete the server, we need a minimalistic dataserver. First tell DirtSand where we are going to put it. In the "Paths" section of dirtsand.ini, change the following options (again replacing "<user>" by your username, and assume you used the default setup suggested by the DirtSand introduction):

File.Root = /home/<user>/dirtsand/data
Auth.Root = /home/<user>/dirtsand/data

We do not want to actually put any data on the dataserver so that you can still put whatever you want into the client folder. However, 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.

Server startup

You are now ready to start the server and let it wait for a client to connect to:

bin/dirtsand dirtsand.ini
ds-902> addacct username password

The addacct command creates an account on the server that you can use to log in with the client.

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. If this is not the machine that you compiled CWE on (or if you want to install it on a second computer), download and install the PhsyX System Software.
  5. From the "dll" directory of the devlib.zip file, copy python27.dll if you created a Release build, or python27_d.dll if you created a Debug build.
  6. From the CWE build directory, copy the client (".../build" refers to the build directory you chose in CMake during CWE compilation)
    • If you created a Debug build, that file is at ".../build/Sources/Plasma/Apps/plClient/Debug/plClient.exe".
    • If you created a Release build, that file is at ".../build/Sources/Plasma/Apps/plClient/Release/plClient.exe".
  7. Download the resource.dat file and put it into the CWE folder as well (it contains cursors and images for the client).

Now the client just needs to be configured. Create an empty filed called "server.ini" with only two lines, telling Uru where to connect to your server:

Server.Gate.Host "123.45.67.89"
Server.Auth.Host "123.45.67.89"

Of course you need to replace the IP address with the one you also used for the dirtsand.ini configuration file.

Now the client is ready, however it needs to be started with additional command-line parameters to work without a proper dataserver. The easiest way to achieve that is to create a shortcut to plClient.exe into your desktop, then right-click and edit it ("Properties"). Select the "Target" field, and add " -LocalData" to it's end. Make sure there is a space between "plClient.exe" and the parameter!

Now you are ready to double-click the shortcut, enter the credentials you choose (when you typed the "addacct" command), and log in to your own, private Shard!

Limitations

There are two fundamental limitations to this Shard, which is why you should not use it for anything but testing:

  • No dataserver: Uru assumes every client to have exactly the same set of files, which is usually ensured by a dataserver. This setup lacks such an auto-update mechanism, to make it easier for you to test new ages. This however means that the sychronization has to be done manually, which of course only works for very controlled environments.
  • No encryption: To make the setup easier, the connection between client and server is not encrypted. This allow replay-attacks to log in to another user's account if you can sniff their network connection. A production-style server should use encryption. See the README file shipped with DirtSand for how to do that.