Configuration Guide
Stargate can be configured through three files:
The config.yml file can be found by default in the Stargate folder; a copy of the most recent version can be found here.
This file is intended to be of use to all administrators, and as such, it has been thoroughly commented for ease-of-use.
For settings that can be especially complex, the below info can be used in addition to the comments mentioned above.
On startup, stargate iterates through its databases to determine that all portals listed are still present and valid.
Invalid portals will be removed from the database and will cease to function; valid portals will be left alone.
The most common causes for portal invalidity are external plugin operations (worldedit, rollbacks, etc.) and removed or modified .gate files.
Although disabling this function can allow modified .gate files to continue functioning, it will usually lead to unintended behaviours (including ghost portals)!
When deducting costs, stargate opts by default to delete collected funds.
If this setting is not blank, stargate will instead send any such funds to the specified taxAccount.
Currently, SG uses Vault, and as such, the bank account should be a UUID.
In future, other economy APIs will be supported, and as such, string-based bank accounts will be supported.
Note
The SG-Customizations module provides a more robust style and configuration system.
If you find that signFormatting gets ignored, check the value of StargateCustomizations/config.yml (if it exists).
When formatting a gate's sign, SG will take these settings into account.
The color option is used to specify a ChatColor to be used by most text on most signs.
Stargate will subtly adjust this colour to ensure readability regardless of sign material.
For example, specifying AQUA will result in dark blue text on light signs such as birch, and light blue text on dark signs such as dark oak.
The pointer option is used to specify how SG accentuates a player's active or selected destination.
Currently, Stargate's core supports three pointer colour themes/styles.
-
Regardless of circumstance, all text on the sign (including pointers) will revert to
color(specified above). -
When scrolling, pointers will adopt colours indicating the destination portal type (flags on the destination portal).
-
When scrolling, pointers will always adopt a colour slightly offset from the rest of the text, as to ensure emphasis.
Gate flags with colours are listed in this file.
Some plugins allow the colour of the text displayed on a sign to be modified through the use of a specified character.
Most commonly (for example, as used in EssentialsX), that character is &; for example, &1 is blue, and ♂FF is light blue, and &2 is green.
By default, if someone names a gate in such a way as for it to be coloured by another plugin, StarGate will allow this to occur, overriding signStyle.listing in the process.
For example, &1Example will result in a gate that appears to be named "Example", but is displayed in blue text.
Note that SG will still handle gates by their specified name internally; &1Example and &2Example are different gates.
That is to say, although they will display as gates of the same name (albeit with different colours), they are separate -- unrelated -- gates.
When this setting (disableCustomColoredNames) is true, stargate will force the game to display the signs as written.
For example, stargate will prevent plugins from transforming a gate named &1Example into one named Example (albeit displayed in blue).
Although not generated by default, if bungee.remoteDatabaseSettings.advancedDatabaseConfiguration is set to true in config.yml, a hikari.properties file will be generated in your StarGate folder.
When present, this file will override all remoteDatabaseSettings provided, in favour of those provided in the hikari.properties.
This file is intended to be of use to advanced administrators operating large networks.
It has been minimally commented and relies on a basic understanding of relational databases.
For more information about Hikiari's properties file and its associated settings, see this link.
There are some additional configuration options that are not added to config.yml by default.
If you manually write certain keys at the end of your file, you can access some obscure features.
These properties are poorly supported, unstable, and rarely used.
Generally speaking, you should never need to use any of these.
When interacting with these properties, it is generally assumed that you already know what you are doing.
These keys are poorly documented; if you don't already know what one does, you probably shouldn't be using it.
Documentation: View Source Code (Advanced keys end in true)
Possible Key Values:
#Currently Implemented
legacyBungeeNetwork:
#Coming Soon:
gateSpecificBehaviour:
underwaterActivators:
generalActivators:
enableOwnedGates: