katafractari / rocketminsta Goto Github PK

RocketMinsta is a major game modification for Nexuiz 2.5.2 servers.

The RocketMinsta mod ("RM") extends the MinstaGib + Grappling Hook mutators by modifying the minsta gun, adding new play modes (Freeze Tag, VIP, and Total Domination) to the standard ones (Capture the Flag, Key Hunt, and Domination), and including significant HUD improvements for connected Nexuiz clients.  It also fixes several Nexuiz bugs and includes certain features from Xonotic and nexuiz-svn. Classic Nexuiz and the standard MinstaGib mode are still supported for server operators who just want the benefits of the fixes.


 -- Basic Installation --

To get the RM mod running on your server, you will need a QuakeC compiler installed.  (We recommend "fteqcc" from this repository: git://git.xonotic.org/xonotic/fteqcc.git ).

Once you have built or installed a QuakeC compiler, then duplicate and rename the RocketMinsta file "EXAMPLE_config.sh" to "config.sh".  This file is the configuration file for build.sh, which is used to compile and install the mod.  Open this new file in your preferred text editor.

Items that you'll probably need to change in this config file are the NEXDATA and QCC variables.  NEXDATA is the directory where mod files will be installed.  If you are building RM on your server machine, you most likely should set NEXDATA to the ~/.nexuiz/data/ directory of the user account in which your Nexuiz server runs.  Otherwise, you should create a separate directory (outside of your cloned repository) for the mod, and then manually copy files from there into your server's Nexuiz data folder. The QCC variable is an ordered list of QuakeC compilers to try.  If no QuakeC compilers are present, the build script will give up.  If the fteqcc binary is not in your PATH, you should append its location to the QCC list.  Save the config when you're done editing it.

Now, run "build.sh".  After the installation has completed, the script will tell you what should be done next.  (NOTE: if you're not building on your server machine, you should copy relevant files later manually.)  It is possible to automate remote installations over SFTP, as discussed in the "Release System" section below.

At this point, you may also want to take a look at the RocketMinsta mod's default settings.  They are found in "rocketminsta.cfg".  WARNING: you should NOT edit the "rocketminsta.cfg" file!  Instead, put any changes and customizations into your server config file instead.  It's also recommended that you keep your RM configuration separate, and reference it from your main config with an "exec".


 -- Client Packages --

The build script will generate several "client packages" (sometimes incorrectly referred to as "server packages").  These are .pk3 files with names like, "zzz-rm-PACKAGENAME-MD5SUM.pk3".  They contain client-side game content for the players, such as new models, sounds, graphics and HUD skins.  When the server executes "rocketminsta.cfg", their identification files will be automatically added to the "sv_curl_serverpackages" list.  However, it is your responsibility to provide a way for them to be downloaded.  If you have a single download server for maps, just adding the generated packages there will work.  For a more complex setup you might want to use the "curl_urls.txt" (refer to the Nexuiz documentation for an explanation of that file).

You can also integrate your own custom packages.  To do this, first create a directory named "c_YOURPACKAGENAME.pk3dir" in the root of your cloned repository and fill it with content (c_*.pk3dir directories will be ignored by git).  After that, alter your config and add your package name into the BUILDPKG_CUSTOM array, like this: BUILDPKG_CUSTOM=('YOURPACKAGENAME').  (Notice the lack of the c_ prefix and the .pk3dir extension.)  Finally, rebuild the mod;  your package will be compressed and added to the resulting installation's "rocketminsta.cfg".


 -- Updating (for builds on the server machine) --

There is a helper script that simplifies the process of updating the repo, reinstalling the mod, and reloading it's configuration on the server (through RCON) down to a single command.  This process uses it's own configuration file, much like using "build.sh", which is customized in the same fashion.

First, copy and rename "EXAMPLE_updconfig.sh" as "updconfig.sh" and edit this new file. The variables RCON_ADDRESS, RCON_PORT, and RCON_PASSWORD should match your server's address, port and rcon_password variable, respectively.  If you haven't customized any RocketMinsta related settings on your server, it's better to replace "exec server.cfg" with "exec rocketminsta.cfg".  If you keep your RM-related configuration separate, then it's good to put "exec rocketminsta.cfg" first, and then "exec what_your_config_is_called.cfg" after it.  If you're using an rm-custom config, then "exec rm-custom/cfgname.cfg" is enough.

Once you're done modifying "updconfig.sh", you can run "./update.sh" whenever you want to update your server.  NOTE 1: update.sh will not do anything unless an update is available.  NOTE 2: update.sh doesn't support rcon_secure yet, so the server must have it off for the upgrade script to work properly. To enforce an update, run "./update.sh force".


 -- Release System --

RocketMinsta features a simple release system, which allows you to quickly generate pre-compiled packages for the end user (server host) to extract over their existing nexdata.  These packages can be customized.

To configure the release system, first copy one of the example configs and rename the copied file "releaseconfig.sh". The configuration options are commented in the example config files, so it shouldn't be a problem to customize the one you chose.  If in doubt about what changes to make, the defaults should work in most cases. Once you're done with any changes, run ./build.sh release to generate a release package. This method will use the main releaseconfig.sh.

The release system also supports custom configs, which have a name of releaseconfig_CONFIGNAME.sh.  (These files, much like other configs, are ignored by git.)  To use one of your custom configurations, try ./build.sh release CONFIGNAME (e.g., with a CONFIGNAME of 'derp', the script will use releaseconfig_derp.sh).

An additional feature of the release system is that it can be used as an upgrade tool, as with the "EXAMPLE_releaseconfig_SFTP.sh" file.  The SFTP example does NOT generate a package; it just uploads its contents to the server.  The SFTP example also utilizes RCON in the same way as update.sh does (as explained above in the "Updating" section).