How-To's


Users and Players

Multicraft makes a difference between users and players. Users are registered control panel users that can use various functions depending on their access rights for a specific server. Players are created as soon as they are seen by a minecraft server. Each server has a separate list of players.
Players can be assigned to users. By doing so the player inherits the role of the user. The players role can also be adjusted without linking it to a user so it is optional for players to register.

Assign Different Roles to Users

You can assign different roles to users, either per-server or globally:


Available User Roles

The following list of available roles is in ascending order, meaning the listed roles include the capabilities of all of the roles above them:



Whitelisting / Private Servers

To make a server private just set its "Default Role" to "No Access". The default role is the role assigned to all users/players that don't have any other role assigned to them.
To allow access for a player to a private server you can either create the player with a role greater than "No Access" or edit the player entry if it already exists.


Commands

You can define new chat commands or change the role required to run built-in commands.
The "Prerequisite" field in the command create/edit form refers to another command that has to be run before this one. Commands fail silently if the user doesn't have the required role.

To run a command the player needs to have a role greater than or equal to the one defined in the command settings and say the string defined in the "chat" setting of the command in-game. To run the command silently (i.e. without printing it in the chat) it can be prefixed with a slash, however, this does not work with all Minecraft versions. 
asay Hello everyone!

When creating a new custom command you can define what is run on the Minecraft server by changing the "Run" field. If the command is preceded by "multicraft:" the command that will be run is the Multicraft command that has the "Chat" field matching the specified string, see the MOTD example below. The following special sequences can be used in a command:
%n The players name
%1, %2, etc. Every %X gets replaced by the X-th argument the player supplied (arguments are space separated)
%s The whole argument string supplied. If %s is used multiple times the argument string is split by spaces as many times as there are %s arguments
%l The players access level
%o Empty string (can be used to separate %1, %2, etc. from a number)

Multiple commands can be separated using a semicolon ";". To escape the semicolon use a backslash "\;". Take care not to insert a space before a command (i.e. after the semicolon) as Minecraft won't interpret that.


Built-in Commands
Built-in commands can be called - just like Minecraft console commands - by using them in the "Run" field.
You can also provide parameters in the "Run" field already, for example a command with "builtin:tell_level admin" in "Run" will cause a message to be sent to every player who is an admin. The player doesn't have to specify the level himself because it's already provided.

Command Parameters
builtin:asay message Prints "message" as the server
builtin:backup Creates a new backup zip file
builtin:date Prints the current date
builtin:give id [amount] Gives the player the item with id "id". If amount is not specified 64 blocks are given.
builtin:kick target Kicks "target" from the server
builtin:list Tells the list of players on the server to the player
builtin:restart Restarts the server
builtin:restart_empty Restarts the server only if no players are online
builtin:save Saves the world
builtin:saylist Prints the list of players on the server to everyone
builtin:script name Runs the script "name". The script has to be defined in the scripts.conf file
builtin:start Starts the server
builtin:stop Shuts down the server
builtin:stop_empty Shuts down the server if no players are online
builtin:summon target Teleports "target" to the player
builtin:tell_level level message Tells "message" to all players with their level greater than or equal to "level". "level" can be numeric or one of: user, mod, admin, owner
builtin:time Prints the current time
builtin:tp target Teleports the player to "target"
builtin:tp_other player1 player2 Teleports "player1" to "player2"


Running Scripts
The built-in command "builtin:script" enables the users to run scripts you have defined for them in a special config file. By default this config file is called "scripts.conf" and expected to be in the Multicraft base directory (where the multicraft.log lies). You can change the path/name of this file in your multicraft.conf.
The format of the file is: 
[cmd1]
servers=all
command={BASE_DIR}/script1.sh

[cmd2]
servers=2,3,7
command={BASE_DIR}/script2.sh

[dangerous]
servers=1
command={SERVER_DIR}/userscript.sh
The value in the [] brackets is what the user puts after "builtin:script". "servers" lists the server IDs of all servers that can run this command ("all" for all servers). "command" is the path to the script to run. The last command is called "dangerous" because it runs a script that lies in the server directory which means that the user can modify this script.

The following placeholders can be used in "command":
Placeholder Example
{BASE_DIR} /home/minecraft/multicraft The base Multicraft installation directory
{DAEMON_DIR} /home/minecraft/multicraft/bin The path to the Multicraft daemon executable
{DATA_DIR} /home/minecraft/multicraft/data The path to the daemon database (if using SQLite)
{JAR_DIR} /home/minecraft/multicraft/jar The path to the JAR directory
{SERVERS_DIR} /home/minecraft/multicraft/servers The directory that contains all the server base directories
{SERVER_ID} 6 The server ID of the server running the command
{SERVER_DIR} /home/minecraft/multicraft/servers/server6 The base directory of the server running the command
{WORLD} world The name of the current world
{JAVA} java The default Java executable
{START_MEMORY} 1024 The amount of memory allocated on server startup
{MAX_MEMORY} 1024 The memory limit for this server
{JAR_FILE} minecraft_server.jar The JAR file used by this server
{JAR} /home/minecraft/multicraft/jar/minecraft_server.jar The full path of the JAR in use
{IP} 192.168.1.24 The IP of the server
{PORT} 25565 The port of the server
{MAX_PLAYERS} 16 The number of player slots for this server
{DAEMON_ID} 1 The ID of the daemon controlling this server
{PID} 2589 The process ID of the running server process
{PID_FILE} /home/minecraft/multicraft/servers/6.pid The file containing the servers process ID

In the script itself you'll have access to the same values listed above through environment variables. The base directory, for example, can be output using 
echo Base directory: $BASE_DIR


Special Scripts
The following script names are reserved as they have special functions:
Script name
setup This script is run when a server is initially setup. This only works when the daemon is online at the time the panel issues the command to run this script
_started This script is run as soon as the server has finished its startup sequence.
_stopped This script is run after the server has been stopped.


Examples


Custom JAR Files

We do not take any responsibility for any of the links used in this and the following sections regarding custom JARs. These links are provided by the JAR authors themselves and they are not checked by us

All that is required to use a different server JAR is to place the file in the "jar" directory of your Multicraft installation and then set the "JAR File" field in your server settings to the name of the new file.
This will work fine for a vanilla Minecraft JAR, however, Craftbukkit JARs and other mods require different settings as their console output differs from the one of vanilla Minecraft. Also, just placing the JAR file in there will not make it appear in the JAR selection so users can't select it.

This is where the ".jar.conf" files come into play. These files are used to determine the JAR file selection in the server settings and they are also capable of completely reconfiguring the output that Multicraft expects from the server. They are flexible enough to even run different Games with the correct settings.

For most users the supplied .jar.conf files will be enough. If you put a new Craftbukkit JAR in place you can just copy the existing "craftbukkit.jar.conf" to a new name, e.g. "craftbukkit_dev.jar.conf" and then edit the .conf file to match the new JAR settings. The most important setting to change would be the "name" setting so it can be distinguished from the other JARs in the selection. The "source" and "configSource" settings should also be changed to make sure it's not overwritten with the files listed in the old .conf. The "source" setting defines where the JAR is downloaded when the update function in the panel is used, the "configSource" setting defines where the .conf file can update itself from (if you don't change that your .conf will be overwritten with whatever is found under "configSource" the next time you update the .conf file).

Most of the settings in the .conf files are documented directly in the comments of the default craftbukkit.jar.conf files supplied with Multicraft. For advanced use of these files please see the ".jar.conf Files" Documentation page.


Defining which .conf file to use

By default Multicraft will use a conf file with the same name as the JAR file used. For example, using "minecraft_server.jar" will use the .conf file "minecraft_server.jar.conf".
With the 2.0.0 release Multicraft supports using .conf files by matching the JAR name against a regular expression. You can find the full documentation of this feature in the "server_configs.conf.dist" file that ships with Multicraft. Simply rename this file to "server_configs.conf" and edit it to suit your needs. No daemon restart is required for these changes to take effect.

Example: 
[match]
canarymod.jar.conf=canary
This will use the file "canarymor.jar.conf" for any JAR file that contains "canary" in the name.


Default settings for all JARs

Starting with 2.0.0 Multicraft will read the default settings to use for all JARs from the config file "default_server.conf". You can rename the "default_server.conf.dist" that ships with Multicraft to "default_server.conf" and edit the file to your needs to override the default values. Whenever no .conf file is found or the .conf filed doesn't explicitly set a value the values from this file will be used.


CanaryMod

You can simply download the canarymod.jar.conf file and place it in the "jar" directory of your daemon to be able to use CanaryMod like Craftbukkit or vanilla Minecraft.

Alternatively you can directly add CanaryMod in your panel using the following values under Settings->Update Minecraft->Add or Remove Files:

The "File URL" is: 
http://dl.visualillusionsent.net/minecraft/CanaryMod/latest.php
The "Conf URL" is: 
http://www.multicraft.org/download/conf/?file=canarymod.jar.conf

Tekkit/FTB

Tekkit/FTB and similar mods can be run using the craftbukkit.jar.conf but please note that they are not officially supported at the moment. According to user feedback, the following instructions can be used to set up such a server:
Video Tutorial
Jacklin213 has created a YouTube video detailing the process of installing Tekkit with Multicraft.

Forge

Forge can be run using the craftbukkit.jar.conf with a few modifications but please note that it's not officially supported at the moment. According to user feedback, the following instructions can be used to set up such a server:


StarMade

StarMade can be run using the StarMade.jar.conf file below but please note that StarMade is not officially supported at the moment. According to user feedback, the following instructions can be used to set up a StarMade server:

PocketMine-MP

PocketMine-MP can be run using the pocketmine.phar.conf file below. Thank you to Shoghi from pocketmine.net for providing this file!
The following instructions can be used to start a PocketMine-MP server:

Spigot and BungeeCord

You can simply download the spigot.jar.conf or bungeecord.jar.conf file and place it in the "jar" directory of your daemon to be able to use Spigot/BungeeCord like Craftbukkit or vanilla Minecraft.

Alternatively you can directly add Spigot/BungeeCord in your panel using the following values under Settings->Update Minecraft->Add or Remove Files:

In the first field enter either "spigot.jar" or "bungeecord.jar". Leave the "File URL" empty and for the "Conf URL" enter one of the following depending on the JAR you wish to install:
http://www.multicraft.org/download/conf/?file=spigot.jar.conf
or 
http://www.multicraft.org/download/conf/?file=bungeecord.jar.conf

You can then go to Settings->Update Minecraft, select the new entry and update the "JAR" file normally.


Bedrock

Linux
Windows


User Contribution: Updating BuildTools and Spigot (Windows Standalone)

Disclaimer: These are user contributed items, neither multicraft.org/xhost.ch GmbH nor the providing party assume any warranty whatsoever for any outcome as a result of using any of the listed scripts, programs, instructions or other items.

BuildTools and Spigot update script by RedstoneFiend

Make sure to edit the script and change "C:\Bitnami" to the path to your Bitnami installation directory. Also, the "Updater" directory needs to be created inside this directory before running the script.


Server Templates (new in 2.0.0)

The server template feature has been added in Multicraft 2.0.0 to make it easier to deploy mods and pre-installed servers. Templates can consist of files and scripts that are used to initialize the server directory.

The basic function of a template is to provide a set of files that will be copied to the server directory before the server starts. To achieve this all you have to do is to create a new folder in the "templates" directory of your daemon (by default "/home/minecraft/multicraft/templates") and put all files you want to have copied to a server into the "files" directory within your new template folder.

You can also create a template.conf file and use it to give your template a user readable name and configure some other settings such as the JAR file setting the server should be set to after using this template. The template.conf of the example template supplied with Multicraft (in the folder "cleanmodsplugins") contains extensive documentation of all available settings in the comments.

A more advanced template can also run scripts at various steps in the template setup process. Please see the readme.txt in the "templates" directory of your daemon or in the Multicraft package for more information on this feature.

Mod auto-setup

Certain mods require additional files to work correctly. Using a simple template you can make Multicraft automatically copy the files into the server directory when the sever starts. By default the template will still have to be selected for installation by the user. There are two additional steps you can take to change the behavior of automated mod setup:

Suggesting templates for JARs

To make sure the user knows about the correct template for a selected JAR you can use the "suggestTemplate" setting in the .jar.conf file of your JAR file, for example: 
[settings]
suggestTemplate = template1
This will ask the user to use the sample template and forward them to the "Setup" page with the correct values already filled in.

Automatically installing templates

Instead of having the user confirm the tempate to install you can also silently force the template to be installed whenever the server is switched to a JAR by using the "forceTemplate" setting in the .jar.conf file of your JAR file, for example: 
[settings]
forceTemplate = template1

You can modify the behavior using two additional flags: These flags can also be combined, for example "always,delete". To have a template named "template1" be installed on every server start, the setting would be:
forceTemplate = template1|always

Examples

Simple templates for installing additional mod files
In it's simplest form a template is just a directory that contains a "files" directory with any kind of files in it. Upon installation of the template the files in the "files" directory will be copied to the server directory. The name of the template is the name of the directory within your "templates" directory. For example, two templates named "template1" and "template2" might look like this:

To have a JAR file install "template1" when that JAR file is selected, set the following in the .jar.conf file: 
forceTemplate = template1
In this example that would cause the file "MOD FILES HERE" to be copied to the server directory the first time the server is started using this JAR.

Copy an additional test.conf file to the server directory 
copyfile.zip/                           # Can either be a zip file or a plain directory
             template.conf              # The template configuration, optional
             files/                     # Everything in here will be copied to the server directory
                   test.conf
template.conf contents: 
[general]
name=Copy test.conf

Configure the server with an additional config file, print a message before installing the template, do post processing using a script, enable certain server startup parameters, disallow deleting the server directory as part of the template installation 
configure.zip/
              afterSetup.sh             # This script will be run after the setup has been completed
              template.conf
              files/
                    some_config.conf
template.conf contents: 
[general]
name=Configure Server for MOD
setParams=1,3

[setup]
neverDelete=true

[commands]
initialize=/bin/echo Server Configuration set to MOD

Copy additional mod files to the server and set the JAR file of the server to use that new mod 
craftbukkit.zip/
                template.conf
                files/
                      Additional mod files required
template.conf contents: 
[general]
name=Install Craftbukkit
setJarFile=craftbukkit.jar


Using MySQL / Controlling a remote server

The Multicraft control panel can connect to a daemon running on a remote machine. To enable this you have to use a MySQL database to which both the control panel and the daemon on the remote machine can connect.

Configuring the daemon

Edit your "multicraft.conf" and set the "database" setting to the shared MySQL database. Be sure to also fill in the "dbUser" and "dbPassword" settings. For example if your MySQL server is running on 1.2.3.4:
database = mysql:host=1.2.3.4;dbname=multicraft_daemon
dbUser = *your MySQL user*
dbPassword = *your MySQL password*
Replace the database name (here "multicraft_daemon") and the user and password accordingly.

By default the daemon listens on the IP address "127.0.0.1" which means only connections from the local machine will be allowed. To allow the panel to connect to the daemon from the outside edit your "multicraft.conf" and change the "ip" setting to the internet IP. If the daemon is running behind a router, set "ip" to 0.0.0.0 and "externalIp" to your external IP. For example, if the internet address of your daemon machine is 2.3.4.5:
ip = 2.3.4.5

After changing the "ip" setting anyone can connect to it so make sure to set a strong daemon password in your "multicraft.conf" using the "password" setting, for example: 
password = *strong daemon password*
Note that in the panel configuration instructions below we'll refer to this password in the last step of the installer.


Configuring the panel

If you still have the installer (install.php) in place you can re-run it and under "Daemon Database" put in the information of the shared database. If you've already deleted the installer script you can manually edit the file "protected/config/config.php" and set "daemon_db", "daemon_db_user", "daemon_db_pass" to match the information you have put in your "multicraft.conf".

If the database is not yet initialized you can use the installer (install.php) to initialize it.

The same daemon password you have put in your multicraft.conf has to be used on the panel as well, you can either change the setting "Password for daemon connection" in the last step of the installer or you can manually edit the file "protected/config/config.php" and set "daemon_password" to your daemon password.

Example:
    'daemon_db' => 'mysql:host=1.2.3.4;dbname=multicraft_daemon',
    'daemon_db_user' => '*your MySQL user*',
    'daemon_db_pass' => '*your MySQL password*',
    'daemon_password' => '*strong daemon password*',


Configuring MySQL

The above assumes that your MySQL server is already accepting remote connections. If this is not the case you have to configure MySQL to do so.

Secure MySQL

A first step should always be to run "mysql_secure_installation": 
mysql_secure_installation
Say "Y" to all questions (except for the first one if you don't want to change the root password).

Change the Listen Address

Edit your "my.cnf" and change the "bind-address" setting to your internet IP. If the setting does not exist you can create it in the "[mysqld]" section of that file. Make sure to remove any line that reads "skip-networking". For example, if the internet IP of your MySQL server is 1.2.3.4: 
bind-address=1.2.3.4
#skip-networking
Then restart MySQL: 
service mysql restart
The service might be called differently on your system, for example "mysqld" instead of "mysql".

Grant Access to Daemon MySQL Users

The following queries are run directly in MySQL. You can use any tool to access MySQL, from the command line it would be: 
mysql -uroot -p
Replace "root" with the name of a privileged MySQL user.

It's recommended to create a new MySQL user for each daemon. For example if your daemon is running on 2.3.4.5: 
GRANT ALL ON multicraft_daemon.* TO daemon1@'2.3.4.5' IDENTIFIED BY 'mysql_password_for_daemon1';
In the "multicraft.conf" of daemon 1 you would then put: 
database = mysql:host=1.2.3.4;dbname=multicraft_daemon
dbUser = daemon1
dbPassword = mysql_password_for_daemon1

It's also possible to use the same user for all daemons. In that case you'd replace "TO daemon1@'2.3.4.5'" with "TO daemon@'%'" in the above example.

You can further restrict the database access of daemon users based on the following security recommendation: Separate Daemon and Panel Databases

Open Firewall / Router for MySQL

If you are behind a firewall or a router make sure that the MySQL server is accessible by the daemons. The default MySQL port is 3306. If you are using a different port you can adapt the "database" setting in your "multicraft.conf" accordingly, for example if the MySQL server is running on port 2345: 
database = mysql:host=1.2.3.4;dbname=multicraft_daemon;port=2345

You can test if MySQL has been configured correctly from the command line of the daemon machine: 
mysql -h 1.2.3.4 -u daemon1 -p multicraft_daemon
You should now be able to log in with the MySQL password you have set for daemon 1 earlier.


Cloud Installation / Mass Deployment

With the Dynamic license one Multicraft control panel can manage multiple Minecraft instances distributed over multiple physical or virtual machines.

To use Multicraft in such a configuration: Once this is done each server can dynamically be assigned to one of the running daemons directly in the server settings. The daemons are automatically detected as soon as they are started trough an entry they create in the shared database.


Adding Region Fixer support

Multicraft comes with a feature that allows you to run an arbitraty world repair tool, for example "Region Fixer" (View on GitHub).
In order to configure Multicraft to use Region Fixer you can use the following instructions:



Changing the port of the standalone webserver (Windows)

If your port 80 (or 443 for HTTPS) is already in use by something else the installer will automatically ask you which port it should use.

Changing the port after the installation is possible as well. You can simply edit the file "Multicraft\config\httpd.conf" and change the SRVPORT and/or SRVPORT_SSL settings at the top as needed.

After completing these changes you need to restart the "Multicraft apache" service in the Windows Services panel.


How do I get FTP access to my server?

There is a YouTube video explaining this:
Multicraft Short: Give FTP access to a user

Accepting the Minecraft EULA

Minecraft versions after 1.7.9 require you create a file called eula.txt that contains the line "eula=true" in your server directory.

For individual servers

If you just want to accept the eula for your server it is sufficient to create this file or change the line to "eula=true" if it already exists. You can use your panel FTP file access to achieve this.


For server providers

Users can use their FTP access to edit the eula.txt file as mentioned above. If you want to facilitate accepting the EULA or even automate it there are several ways you can do that using Multicraft. Below you will find a few examples.


Example 1 - Add a config file entry
You can configure the panel to treat the new eula.txt as a server configuration file so users can change it without editing the file manually. Simply go to "Settings"->"Config File Settings" and click on "New Config File Setting". Fill in the fields like this:

NameMinecraft EULA
EnabledTrue
Fileeula.txt
Options{"eula":{"name":"Accept Minecraft EULA","select":"bool"}}
TypeProperty File

Your users can then accept the EULA by going to "Files"->"Config Files"->"Minecraft EULA".



Example 2 - Add an "Accept EULA" button to the server settings (advanced)
On your panel, add the following code to "protected/controllers/ServerController.php" after line 172: 
            case 'accept_eula':
                if (Yii::app()->user->can($id, 'edit')
                    && !McBridge::get()->serverCmd($id, 'run:builtin:script accept_eula')) {
                    echo McBridge::get()->lastError();
                }
                break;
Add the following code to "protected/views/server/view.php" after line 368: 
    $attribs[] = array('label'=>Yii::t('mc', 'Minecraft EULA'), 'type'=>'raw',
        'value'=>CHtml::ajaxButton(Yii::t('mc', 'Accept EULA'), '', array(
            'type'=>'POST',
            'data'=>array('ajax'=>'accept_eula', Yii::app()->request->csrfTokenName=>Yii::app()->request->csrfToken,),
            'success'=>'function(e) {if (e) alert(e);}')));

Then on the daemon, create or edit the file "scripts.conf" in your daemon directory (next to the multicraft.conf file) and add: 
[accept_eula]
command={BASE_DIR}/scripts/accept_eula.sh

and create a file called "accept_eula.sh" in the "scripts" directory that contains: 
#!/bin/sh
echo 'eula=true' > "$SERVER_DIR/eula.txt"
And make sure it can be executed: 
# chmod 755 scripts/accept_eula.sh

Please note that the script needs to use the Unix line ending format so it's recommended to create it directly under Linux instead of creating it under Windows and uploading it.

Your users can now click this button to automatically create the eula.txt file.



Example 3 - Automatically create the file (advanced, Linux multiuser only)
This is similar to the suggestion above but the script will be run automatically every time a server starts. You need to make sure your users are informed about the EULA and this acceptance.
To enable the script, simply change the "userAgentPrepare" setting in your multicraft.conf to: 
userAgentPrepare=scripts/accept_eula.sh
Make sure that there is no # in front of that line. After the change the daemon needs to be restarted for the change to take effect.

The script can be created the same way as described in the previous point:
Create a file called "accept_eula.sh" in the "scripts" directory that contains: 
#!/bin/sh
echo 'eula=true' > "$SERVER_DIR/eula.txt"
And make sure it can be executed: 
# chmod 755 scripts/accept_eula.sh

Please note that the script needs to use the Unix line ending format so it's recommended to create it directly under Linux instead of creating it under Windows and uploading it.

This script will now run every time a server starts.


Limit Disk Space / Quota Support (Linux only, new in 2.0.0)

If you have already configured Quota support for your system you can enable the Multicraft quota feature by editing your multicraft.conf file and changing: 
#enableQuota = false
to 
enableQuota = true
or by adding the setting to the [system] section if it does not exist yet. The other "quota*" settings can be used to fine tune this feature.
The daemon has to be restarted for the enableQuota setting change to take effect.


Configure Linux Quota

If you have not yet enabled quota support on your Linux system you can do so by following these steps:

  1. Install the "quota" package, for example: 
    apt-get install quota
    or 
    yum install quota

  2. Edit the file /etc/fstab and add usrjquota=aquota.user,jqfmt=vfsv0 to the mount options of the filesystem where your servers will be located. For example, change: 
    /dev/sda1 /home ext4 defaults 1 1
    to 
    /dev/sda1 /home ext4 defaults,usrjquota=aquota.user,jqfmt=vfsv0 1 1

  3. Remount the filesystem, create initial quota files, enable quota: 
    mount -o remount /home
quotacheck -avum
quotaon -avu
    Replace /home with the path to the filesystem you want to enable quota for.


Configure User Friendly URLs

You can configure the panel to show user friendly URLs, for example: 
http://example.com/server/1
instead of: 
http://example.com/index.php?r=server/view&id=1

To achieve this you can edit the file protected/config/internal/application.php and look for the following section: 
           // uncomment the following to enable URLs in the format index.php/server/1
            /*'urlFormat'=>'path',*/
            // uncomment the following to hide the index.php part of the URL
            /*'showScriptName'=>false,*/
Simply remove the "/*" and "*/" around the "urlFormat" and "showScriptName" settings to activate them. Note that the apache rewrite module (mod_rewrite) is required for these settings to work correctly. It's possible that these settings do not work correctly on your system and we do not provide official support for enabling them.


Change the Console Direction

The direction of the console/server log is configurable under "Settings"->"Panel Configuration" using the setting "Show console from bottom to top". The default setting is "No" (console goes from top to bottom).


Send mails using SMTP instead of PHP mail()

If you want to send emails directly through an SMTP server instead of using the PHP mail() function you can edit the file protected/config/internal/application.php and look for the line: 
'transportType'=>'smtp'
Remove the "/*" and "*/" around this block of code and configure the values accordingly to use your SMTP server.


Daemon Callbacks

The daemon allows you to hook into and influence certain events. You can configure callback scripts for these events that get passed a JSON string with the callback arguments. The return value is expected to be JSON formated as well.
These callbacks can be configured in the [advanced] section of the multicraft.conf file like this: 
[advanced]
callbackServerStart = /path/to/script.py
callbackServerStop = /path/to/script.py
callbackServerLogLine = /path/to/script.py
callbackServerChatMsg = /path/to/script.py
callbackServerPlayerConnected = /path/to/script.py
callbackServerPlayerDisconnected = /path/to/script.py
callbackServerGetResourceUsage = /path/to/script.py (2.4.0+)
callbackServerCommand = /path/to/script.py (2.4.0+)

Parameters marked with a * are mutable, meaning you can return them in the JSON response with a different value to override them.
The return value of the script has to be 0 on success and any other value on failure. Cancelable events will be canceled on failure.
Callback Parameters Cancelable
callbackServerStart id (int)
ip* (string)
port* (int)
players* (integer)
memory* (integer)
start_memory* (integer)
world* (string)
working_directory* (string)
jarfile* (string)
template* (string)
setup* (string)		 Yes
callbackServerStop id (int)
ip (string)
port (int)
players (integer)
memory (integer)
start_memory (integer, 2.4.0+)
world (string)
working_directory (string)
jarfile (string)
template (string, 2.4.0+)
setup (string, 2.4.0+)
state (string)		 Yes
callbackServerLogLine id (int)
line* (string)		 Yes
callbackServerChatMsg id (int)
time* (string)
sender* (string)
message* (string)		 Yes
callbackServerPlayerConnected id (int)
player_id* (int)
player_name* (string)
player_ip* (string)
player_banned* (string)
player_level* (int)		 No
callbackServerPlayerDisconnected id (int)
player_id* (int)
player_name* (string)
player_ip* (string)
player_banned* (string)
player_level* (int)		 No
callbackServerGetResourceUsage id (int)
ip (string)
port (int)
players (integer)
memory (integer)
start_memory (integer)
world (string)
working_directory (string)
jarfile (string)
template (string)
setup (string)
pid (int)
cpuUsage* (float)
memoryUsage* (float)
sysMemoryUsage* (float)
memoryRss* (float)
cpuCount* (int)
quotaUsage* (float)		 No
callbackServerCommand id (int)
ip (string)
port (int)
players (integer)
memory (integer)
start_memory (integer)
world (string)
working_directory (string)
jarfile (string)
template (string)
setup (string)
success* (bool)
success_string* (string)
response* (list of strings/dicts)		 No

Example for script argument and return value: 
{"setup":"","ip":"1.2.3.4","start_memory":1024,"port":25565,"players":8,"working_directory":"","template":"","memory":1024,"world":"world","id":1,"jarfile":"minecraft_server.jar"}


Windows Standalone: Update Java



Different Java Versions

By default the .jar.conf files call Java through the {JAVA} variable in the "command" setting, e.g.: 
[start]
command = "{JAVA}" -Xmx{MAX_MEMORY}M -Xms{START_MEMORY}M -jar "{JAR}" nogui
This variable will simply be replaced by the "java" setting in your multicraft.conf file, by default: 
java = /usr/bin/java
You can change this setting to the path of the "java" binary you'd like to use.

If the different server types you offer require different Java versions it's no longer possible to use the same {JAVA} variable in all .jar.conf files. Instead you can use the path to the correct version of Java directly in that "command" setting, e.g.: 
[start]
command = /usr/bin/java -Xmx{MAX_MEMORY}M -Xms{START_MEMORY}M -jar "{JAR}" nogui
That way you can ensure each JAR uses the correct Java version and for example keep {JAVA} for the version that is supported by most JARs or that is the current LTS release.