RocketMinsta is a major game modification for Nexuiz 2.5.2 servers.

The RocketMinsta mod extends the MinstaGib + Grappling Hook mutators by modifying the minsta gun (although classic Nexuiz and minstagib are also supported), 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, as well as fixing several Nexuiz bugs and backporting certain features from Xonotic and nexuiz-svn.

 -- Installation --

There are several ways to get the mod running on your server. But first, you will need to install a QuakeC compiller. I suggest FTEQCC from this repository: git://git.xonotic.org/xonotic/fteqcc.git
Once you built/installed it, copy file EXAMPLE_config.sh as config.sh, and then open the resulting file with your preferred text editor. This file is the configuration of build.sh, which is used to compile and install the mod. Things you'll likely need to change are NEXDATA and QCC. NEXDATA is the directory where mod files will be installed. If you build on your server machine, you most likely should set it to the ~/.nexuiz/data/ directory of the user which the Nexuiz server runs by. Otherwise, you should create a separate directory (outside of your cloned repository) for the mod, and then copy files from there into your server's nexuiz data. The QCC variable is an ordered list of QuakeC compilers to try. If none of them are present, the build script will give up. If the fteqcc binary is not in your PATH, you should append it's location to that list. When you're done with the config, save it and then simply run build.sh. After the installation is finished, the script will tell you what should be done next. NOTE: as said above, if you're not building on your server machine, you should copy relevant files later manually. However, it is possible to automate remote installations over SFTP using the release system, it's explained below. You might also want to take a look into RocketMinsta settings, all of them are found in rocketminsta.cfg. However, you should NOT edit this file, put your changes into your server config instead. It's also good to keep your RM configuration separate, and reference it from the main config with an "exec".

 -- Client packages --
The build script will generate several so-called "client packages" (sometimes called "server packages" but I believe this term is plain wrong), which are .pk3 files with names like "zzz-rm-PACKAGENAME-MD5SUM.pk3". They contain various clientside game content for the players such as models, sounds, graphics and HUD skins. Executing rocketminsta.cfg will automatically add their identification files to the sv_curl_serverpackages list, however it is your responsibility to provide downloads for them. 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 curl_urls.txt, refer to the Nexuiz documentation. You can also integrate your own custom packages. To do so, 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. After that you'll have to just rebuild the mod, your package will be compressed and added to the resulting installation's rocketminsta.cfg.

 -- Updating --
note: this section assumes you're building 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. Much like build.sh, it uses it's own configuration file, which is customized in the same fashion: copy EXAMPLE_updconfig.sh as updconfig.sh and edit the later. RCON_ADDRESS, RCON_PORT, and RCON_PASSWORD should match your server's address, port and rcon_password variable, respectively. NOTE: 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, it's good to put "exec rocketminsta.cfg" first, and then "exec what_your_config_is_called.cfg". If you're using an rm-custom config, just "exec rm-custom/cfgname.cfg" is enough. Once you're done, you can forget about this all and just use ./update.sh when you want to update your server. Note: update.sh will not do anything unless an update is available. 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 simply extract over their 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 (with a CONFIGNAME of 'derp', the script will use releaseconfig_derp.sh).

Lastly, the release system can be used as another upgrade tool, as in 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).