@Zorno thanks share whenever you see it ready im very bad at linux
this is the git with all the info
GitHub - rockfireredmoon/iceee: Earth Eternal is an abandoned MMORPG now kept alive by this project. This is the Git repository for TAWD, the server component.
Code:
Configuring The Cluster (all configurations)
Regardless of whether or not you have multiple nodes, you will need to tell the server where your Redis instance is located and how to connect to it.
This source module ships with sample configuration files that must be copied to their 'real' locations. Do this for the local cluster configuration file :-
cp Local/Cluster.txt.sample Local/Cluster.txt
And then open up Local/Cluster.txt in your favourite text editor :-
; The unique name of this shard
ShardName=EE1
; A more descriptive name displayed in the shard selection screen (/shards)
FullName=My Local Earth Eternal server
; The address of this shards Redis instance
Host=127.0.0.1
; The port on which this shards Redis instance is listening
Port=6379
; The password to use to authenticate with the Redis instance. Leave blank or commented out if there is no password
;Password=asecret
This file is also used to set to the unique shard name and description. Do not worry about this if you are only running a single shard.
Configuring The Cluster (multiple shards)
If you wish to run multiple shards in a cluster, there are a few different configurations.
- Multiple server instances pointing to a single shared Redis instance.
- Multiple server instances, each with it's own Redis instance and replication setup between the Redis instances.
- A combination of both.
All replication configuration when multiple Redis instances are used is done at the Redis layer. See https://redis.io/topics/replication
Whenever you have multiple EE server instances, each must have their own Local configuration directory. Anything in this directory is specific to this node only.
Configuring Server Behaviour
All other server behaviour is configured using the Local/ServerConfig.txt file. As with all other configuration files, this is shipped as a ServerConfig.txt.sample, and must be copied and edited before use.
cp Local/ServerConfig.txt.sample Local/ServerConfig.txt
Then edit Local/ServerConfig.txt with your favourite text editor. This file contains many options, most of which are commented. For a new installation, the ones that most likely need to be changed are :-
; The address which is advertised to clients via the 'router' service. This address
; must be resolvable by clients and may either be a hostname or IP address. When blank
; the first public IP address that the simulator service is bound to is used.
SimulatorAddress=localhost
; The address to which the server will bind the simulator and router services. If left
; blank, all detected network interfaces will be used.
;BindAddress=1.2.3.4
..
..
RouterPort=4242 ; Port to listen to router connections (login screen connect)
SimulatorPort=4300 ; Port to listen for simulator connections
HTTPListenPort=8080 ; Port to listen to HTTP requests. Set as zero to disable.
The default configuration will work fine if you are setting up a server for your own use ('localhost'), but if you wish to make the server available to others over the internet, you will at least need to set SimulatorAddress. If you are running multiple servers on the same machine, you can either :-
- Configure an IP address for each server, and use BindAddress in each instances ServerConfig.txt to bind to that address [RECOMMENDED].
- Use the same IP address for each instance, but change RouterPort, SimulatorPort and HTTPListPort in each instances ServerConfig.txt so that ports do not conflict.
NOTE: If you are setting up a cluster, MOST other options should the SAME on all nodes. For example, you do not want each shard to have different values for CapExperienceLevel, but something like MOTD_Message is OK. This will eventually be fixed so such configuration is moved into the cluster database for all shards to share.
Logging Configuration
Logging is provided by EasyLogging (https://muflihun.github.io/easyloggingpp/). See this site for detailed information on how logging is configured.
Server log configuration files are in the Local configuration directory. As with other configuration files, before use you will need to copy the sample file :-
cp Local/LogConfig.txt.sample Local/LogConfig.txt
If you are just starting out, there should be no need to change anything in this file. All logs by default will go to the Logs folder.
Preparing Game Server Data and Client Assets
Having a running EE server on it's own in not much use, you will also need the Game Server Data (i.e. all static data such as Quests, NPC appearances, Scenery and more), and the Client Assets (i.e. all 3D models, Music, Sounds, Client Logic and more).
Game Server Data
We currently have two different Game Server Data sets that will run on this server. They are both stored in a separate GitHub repository - https://github.com/rockfireredmoon/iceee-data. One is for 'The Anubian War' (currently under development), and one for 'Valkal's Shadow' (our current live and active server).
Assuming you are starting from the server source directory, it is recommended you clone the game server data repository into the same parent folder as the server source. This way the default file locations in ServerConfig.txt are all ready setup as needed and ready to go.
For Valkals Shadow on TAW Engine
If you want to work on Valkal's Shadow (on TAW engine), then clone the valkals_shadow branch.
cd ..
git clone -b valkals_shadow https://git@github.com/rockfireredmoon/iceee-data.git
cd iceee
For The Anubian War on TAW Engine
cd ..
git clone https://git@github.com/rockfireredmoon/iceee-data.git
cd iceee
Both of these will go to the parent folder, clone the server data for the 'TAW' version of the game, and then change directory back into the server source folder (if you cloned the server source to somewhere other than 'iceee' folder, change accordingly).
Client Assets
As with the game server data, we have two different versions of the Client Assets. Again, they are both stored in a Git repository under different branches. However, for various reasons we do not currently make this publically available. If you need assets, please contact us and we can provide you with a pre-built bundle.
Pre-built Client Assets
You will be provided with a file name iceee-assets.zip.
Assuming you are starting from the server source directory, it is recommended you unzip this file into the same parent folder as the server source. This way the default file locations in ServerConfig.txt are all ready setup as needed and ready to go.
cd ..
unzip /path/to/iceee-assets.zip
cd iceee
This will go to the parent folder, unzip the assets for the appropriate version of the game, and then change directory back into the server source folder (if you cloned the server source to somewhere other than 'iceee' folder, change accordingly).
Compiled Client Assets
If you have access to Client Assets Git repository, you can compile the assets from source. There are a number of tools you will need installed, see the README.md that will be cloned along with the source.
cd ..
git clone [REDACTED]
cd iceee-assets
ant
cd ../iceee
Running The Server
You now have everything you need to run the server. Assuming you are in the server source directory, run :-
builddir/tawd -C
The server will now start up with a default logging level of INFO output to the console.
Creating The User Accounts
Before logging on to the server using the client, you will need to create a user. The default configuration uses a built in user database.
First off, create an administrator account :-
builddir/eeaccount -i create admin 'mysecret' admin --roles=administrator
You can then create accounts for your Sages (GMs) :-
builddir/eeaccount -i create sage1 'mysecret' sagegrove1 --roles=sage
And finally acccounts for ordinary players
builddir/eeaccount -i create aplayer 'mysecret' playergrove1
There are various other ways by which accounts by created, such as via HTTP calls. These are intended for integration with web sites.
Server Daemon Command Line Options
There are a number of options available to aid debuggging and running the process from service scripts and the like.
| Option |
Arguments |
Description |
|---|
| -d |
None |
Daemonize the server. Once initialized, the process will be forked and placed into the background |
| -C |
None |
Output all logging to the console as well as log files. |
| -p |
[path] |
Location to PIDFILE. The process ID of the server is written to this file once known |
| -c |
[path] |
Location to a Local configuration directory (that contains ServerConfig.txt, LogConfig.txt and Cluster.txt) |
| -I |
None |
Flush log output immediately. Ordinarilly this is buffered to aid performance, but disabling this can help in some debugging situations |
| -L |
[loglevel] |
Set the default log level. Position values for include info, debug, error, fatal, trace, verbose or warning |
[/COLOR]
NOTE: Old versions of Meson use a slightly different command that must be run inside the builddir.
mesonconf --default-library=static -Dprefix=/usr -Dlocalstatedir=/var -Dsysconfdir=/etc -Dlocalconfigdir=/etc/tawd
If you want to install as a service (e.g Windows Service, SystemD Service etc), then add this property as well:-
-Dservice=true
Finally run the install. You will probably need to run this as administrator if the files are installed in system locations (the default) :-
[COLOR=var(--color-prettylights-syntax-constant)]cd builddir [/COLOR]
sudo meson install
Earth eternal sort of
). Will try to get it up and running but it can take a while.
Originally Posted by xlw00tlx
for servers its the securest OS available. Sure, ubuntu is not as its running watchdog process to send data to canonical but its the most easiest and for testing server files i dont care about canonical
Reply With Quote