Basic Host Requirements

From ALFA
Jump to: navigation, search

System Requirements

ALFA strongly recommends that all game servers run a 64-bit OS for the operating system that runs nwn2server. A 32-bit OS does not provide enough address space for many modules to function reliably when hosted by nwn2server.

If nwn2server is hosted in a virtual machine, ALFA recommends that either VMware or Hyper-V be used for the virtualization infrastructure. Both of these products have both been validated and are functional in production use for live servers.

Specifically noted, VirtualBox should not be used or the game will not function properly, on account of bugs in VirtualBox's timer handling (often manifests as perception not working over time or other time-based systems in the game malfunctioning).

It is preferred that the Windows version (Windows 8.1 or Windows Server 2012 R2 or higher are recommended) used to host the game server be a version that supports acting as a Remote Desktop Protocol (RDP) host, typically Professional (or higher) editions. Server editions also include Remote Desktop Protocol host functionality. RDP provides a superior remote administration experience as compared to VNC.

The recommended memory size to allocate to a game server instance is 4GB. This may be adjusted based on the actual memory consumption of a module, but 2GB provides plenty of headroom for most of our servers.

Prerequisites

NWNx4

ALFA uses NWNx4 to host all of its live servers.

While this document cannot replace the documentation provided with NWNx4, a brief explanation can be offered: NWNx4 is an application which runs alongside the nwn2server application, communicating with, running processes for, and altering the data within to achieve functionality which cannot be created without such means.

The NWNx4 application works with a number of community-generated plugins-- libraries of functions and hooks, which are either called from the NWN scripting language or which intercept standard functions or functionality to correct bugs-- which are required for the proper function of ALFA's core ruleset.

ACR plugin downloads

NWNx4 is configured through the nwnx.ini file, which is plain text and contains help text to describe the function of each setting, which is installed to the NWNx4 install directory. Once configured, a server is run through NWNx4 by running one of the NWNx4 executables. The started application will also start nwn2server.

Currently Used Plugins

Server Folder Files

  • NWNScriptJIT.dll -- NWScript JIT support, C# script support
  • NWNScriptJITIntrinsics.dll -- NWScript JIT support, C# script support
  • AuroraServerNetLayer.dll -- bug fixes
  • NWNScriptCompiler.exe -- The script compiler should be somewhere in %PATH%, but it can be placed in the server install directory too. Needed for the content patcher to automatically recompile modules on updates (required, or else the module could break after a content patch).

NWNx4 Folder Files

  • NWNx4_Hook.dll -- Allows script hooking in the first place.
  • NWNScriptCompiler.exe -- Required to allow the content patcher to recompile a module. Take from AdvancedScriptCompiler\NWNScriptCompiler.exe on the ACR repository.
  • xp_AuroraServerNWScript.dll -- Script improvements, C# support, allows workarounds of engine limitations.
  • xp_bugfix.dll -- Bug fixes
  • xp_craft.dll -- Customization of items during live play
  • xp_mysql.dll -- Allows communication with SQL databases
  • xp_objectattributes.dll -- Allows the modification of creatures during live play
  • xp_ServerVault.dll -- Allows vault reads / writes to occur without stopping the main server process
  • xp_srvadmin.dll -- Allows scripts to carry out server administration actions.
  • xp_system.dll --
  • xp_time.dll --
  • MySql.Data.dll -- MySQL client library for CLR scripts.
  • madChook.dll --
  • xp_fastboot.dll --
  • xp_profiler_Hialmar.dll --


As MySql.Data.dll is sometimes regarded as a remote assembly by Windows, you newer versions of windows may need to unblock the assembly. To do this, right click, pick properties, and then on the General tab, look for an Unblock button. If there is one, click it; if there is not, it's not being so regarded.

Configuration

  • AuroraServerNWScript.ini
    AllowManagedScripts=1
  • xp_craft.ini
    • Set the database directory to proper location of the Campaign Database on the machine
  • AuroraServerVault.ini
    • The text within the configuration file explains how to configure the plugin. If this configuration fails, players will be unable to see their vaults.
    • Typical configuration is to set LocalServerVaultPath=C:\NWN2User\servervault , RemoteServerVaultPath=C:\NWN2User\remotevault , SpoolPath=C:\NWN2User\servervaultspool. All three of these can be anywhere, so long as it is clear to anyone doing maintenance what they are ("remote vault" is where bics will be downloaded to for verification, "spool" is where saved bics will be staged for upload, and "local server vault" is the directory from which characters will be played).
    • The text within the configuration file explains how to configure the plugin. If this configuration fails, the server will default to inappropriate settings (such as PvP, download server, or custom GUIs) or requiring the module to be started manually after nwn2server.exe stops.
    • Remember to ensure that the directories specified in the config file exist! They have to be created manually (except for the LocalServerVaultPath which is automatically created by nwn2server.exe, though it can be manually created safely). If the directories don't all exist, the vault won't work correctly and players will not be able to log in.
  • nwnx.ini
    • The ACR requires a temporary directory to run. It can be anywhere that the user who runs the NWNx4 process can write to. It is set in nwn2temp
  • DatabaseConnector.ini
    • DatabaseConnector has only one setting in it, which should look something like:
      • CommandLine=-batch -L 3306:127.0.0.1:3306 -x -a -T -2 -noagent -N -i C:\NWNX4\ssh.ppk alfa@sql.alandfaraway.info
      • C:\NWNX4\ssh.ppk is the private key that you're specified for this server.
        • To create a key pair, use PuttyGen to create a new key with all of the default settings.
        • Save the private key to your NWNx4 directory, and specify that location in the command line
        • Use PuTTy to connect to alfa@sql.alandfaraway.info (as an HDM, you should have credentials for this) and edit (pico is the Linux command) .\alfa\.ssh\authorized_keys to add the public key to the bottom. Then, run (Windows+R) "<file location of putty> alfa@sql.alandfaraway.info -i <file location of your public key>" -- you will be prompted asking if you want to cache the public key from the server you're connecting to. Pick "yes" and close the connection.
  • xp_mysql.ini
    • Set the database credentials up as per standard for the central server. TA, IA, or tech team can help provide credentials. Use StandardQueryLog.txt (formerly xp_mysql.txt) to troubleshoot database connectivity or query problems.
    • Set server = localhost to use the DatabaseConnector managed tunnel (all servers should generally use this). If a Linux sshfs VM is in use instead, set server = linuxhost where linuxhost is the address of the Linux VM (this method is deprecated).

If running multiple servers on one machine, the above configs need to change slightly. In DatabaseConnector.ini, change "3306:127.0.0.1:3306" to "3307:127.0.0.1:3306" and in xp_mysql.ini change "localhost" to "localhost;port=3307".

Installation checklist

See Virtual Machine Setup for an end to end checklist for configuring a game server from scratch, using this guide for reference.