mirror of
https://github.com/arcadiadevs/playerservers-wiki.git
synced 2025-01-29 16:11:19 +01:00
GITBOOK-107: Fixed some typos and incorrect permissions
This commit is contained in:
parent
36eb00cd16
commit
95f8278005
@ -1,7 +1,7 @@
|
||||
# 📜 Current Config files
|
||||
|
||||
{% hint style="info" %}
|
||||
The below page explains how to use this feature on PlayerServers 3. This is only relevant if you're a beta tester. To view this page for PlayerServers 3, click [here.](../legacy/config.md)
|
||||
The below page explains how to use this feature on PlayerServers 3. This is only relevant if you're a beta tester. To view this page for PlayerServers 2, click [here.](../legacy/config.md)
|
||||
{% endhint %}
|
||||
|
||||
Below you can see the contents of the newest BungeeCord PlayerServers configuration file.
|
||||
@ -36,6 +36,10 @@ mysql:
|
||||
debug: false
|
||||
get-from-file: false
|
||||
|
||||
# Should we automatically update the server core to the latest version
|
||||
# for all sub-servers upon server restart?
|
||||
auto-update-server-core: true
|
||||
|
||||
# Where should players be moved after they /stop or /ps kill their server?
|
||||
balancer:
|
||||
- Hub1
|
||||
@ -45,6 +49,47 @@ balancer:
|
||||
# will be equal to player username instead of (for example) aa386b6h
|
||||
use-usernames: true
|
||||
|
||||
|
||||
# Should we use domain name instead of IP address for servers?
|
||||
use-subdomain:
|
||||
# Should we enable custom subdomain formatting?
|
||||
enabled: false
|
||||
|
||||
# What is the API key that we should use?
|
||||
# To create an API token, from the Cloudflare dashboard,
|
||||
# go to My Profile > API Tokens and select Create Token.
|
||||
# When creating the token, select the following permissions:
|
||||
# - Zone > DNS > Edit
|
||||
api-key: ""
|
||||
|
||||
# What is the IP address that we should use?
|
||||
# If you want to use auto-detection, set this to "auto"
|
||||
# If you want to use a specific IP address, set this to the IP address
|
||||
network-ip: "auto"
|
||||
|
||||
# What is the zone ID that we should use?
|
||||
zone-id: ""
|
||||
|
||||
# What is the domain name that we should use?
|
||||
domain: "example.com"
|
||||
|
||||
# What is the subdomain format?
|
||||
# %id% equals to player name or uuid depending on use-usernames option
|
||||
# %uuid% is a random UUID (independent of use-usernames option)
|
||||
# %uuid_short% is a random UUID without dashes (independent of use-usernames option)
|
||||
# %player% is the player name (independent of use-usernames option)
|
||||
# %playeruuid% is the player UUID
|
||||
# %playeruuid_short% is the player UUID without dashes
|
||||
# %timestamp% is a timestamp in milliseconds
|
||||
# %timestampshort% is a timestamp in seconds
|
||||
# %day% is a day of the month
|
||||
# %month% is a month of the year
|
||||
# %year% is a year
|
||||
#
|
||||
# To find out what a UUID looks like, you can use this website:
|
||||
# https://www.uuidgenerator.net
|
||||
sub-domain: "%player%"
|
||||
|
||||
server-name-format:
|
||||
# Should we enable custom server name formatting?
|
||||
enabled: false
|
||||
@ -52,10 +97,10 @@ server-name-format:
|
||||
# Which format should we use?
|
||||
# %id% equals to player name or uuid depending on use-usernames option
|
||||
# %uuid% is a random UUID (independent of use-usernames option)
|
||||
# %uuidshort% is a random UUID without dashes (independent of use-usernames option)
|
||||
# %uuid_short% is a random UUID without dashes (independent of use-usernames option)
|
||||
# %player% is the player name (independent of use-usernames option)
|
||||
# %playeruuid% is the player UUID
|
||||
# %playeruuidshort% is the player UUID without dashes
|
||||
# %playeruuid_short% is the player UUID without dashes
|
||||
# %timestamp% is a timestamp in milliseconds
|
||||
# %timestampshort% is a timestamp in seconds
|
||||
# %day% is a day of the month
|
||||
@ -98,6 +143,16 @@ cpu-limiting:
|
||||
# How much CPU (in %) should we allocate to each PlayerServer?
|
||||
cpu-per-server: 50
|
||||
|
||||
disk-limiting:
|
||||
# Should we use permissions for disk management? If set to true, you MUST give
|
||||
# your players permission playerserver.disk.<amount> (ex: playerserver.disk.256)
|
||||
# or, else, the command will be blocked, and player will not be able to create
|
||||
# the server. If set to false, everyone will have disk-per-server amount of disk.
|
||||
use-permissions: false
|
||||
|
||||
# How much disk (in MB) should we allocate to each PlayerServer?
|
||||
disk-per-server: 1024
|
||||
|
||||
player-limiting:
|
||||
# Should we use permissions for max-players management? If set to true, your
|
||||
# players should have playerserver.players.<amount>. The max amount of players
|
||||
@ -213,9 +268,11 @@ pterodactyl:
|
||||
# which the servers will be deploy.
|
||||
# Location id is the ID of location used for load-balanced deployments.
|
||||
# Nodes under the selected location will be slowly filled up with servers.
|
||||
# MountID is the id of your plugins mount. If you don't have one, set it to -1.
|
||||
nest-id: 0
|
||||
egg-id: 0
|
||||
location-id: 0
|
||||
mount-id: -1
|
||||
|
||||
# Should we print the docker container installation output to the user?
|
||||
# Could be useful for debugging, and nonetheless, it can be cool for the player :)
|
||||
|
@ -11,7 +11,7 @@ In order to begin, you'll need to change a few config options. Make sure your pl
|
||||
```yaml
|
||||
player-limiting:
|
||||
# Should we use permissions for max-players management? If set to true, your
|
||||
# players should have playerserver.players.<amount>. The max amount of players
|
||||
# players should have playerservers.players.<amount>. The max amount of players
|
||||
# that you could give to a single server is 100000. You can also give them
|
||||
# playerserver.players.unlimited - for unlimited players. If the player
|
||||
# has no permission, he'll be able to have unlimited players.
|
||||
@ -26,10 +26,10 @@ player-limiting:
|
||||
|
||||
By enabling use-permissions, the plugin will ignore max-players-per-server option and will use permission-based slots management system.
|
||||
|
||||
The next thing you'll wanna do is to give all the groups that have `playerserver.manage` permission a new permission as following: `playerserver.players.<amount>`. Here's an example in LuckPerms:
|
||||
The next thing you'll wanna do is to give all the groups that have `playerservers.manage` permission a new permission as following: `playerservers.players.<amount>`. Here's an example in LuckPerms:
|
||||
|
||||
```yaml
|
||||
/lp group default permission set playerserver.players.10
|
||||
/lp group default permission set playerservers.players.10
|
||||
```
|
||||
|
||||
If your groups have parent permission, the plugin will give the player the largest possible amount of slots by their permission.
|
||||
|
@ -11,7 +11,7 @@ In order to begin, you'll need to change a few config options. Make sure your pl
|
||||
```yaml
|
||||
plugin-limiting:
|
||||
# Should we use permissions for max-plugins management? If set to true, your
|
||||
# players should have playerserver.plugins.<amount>. The max amount of plugins
|
||||
# players should have playerservers.plugins.<amount>. The max amount of plugins
|
||||
# that you could give to a single server is 20000. You can also give them
|
||||
# playerserver.plugins.unlimited - for unlimited plugins. If the player
|
||||
# has no permission, he'll be able to have unlimited players.
|
||||
@ -26,10 +26,10 @@ plugin-limiting:
|
||||
|
||||
By enabling use-permissions, the plugin will ignore max-plugins-per-server option and will use permission-based plugin limiting system.
|
||||
|
||||
The next thing you'll wanna do is to give all the groups that have `playerserver.manage` permission a new permission as following: `playerserver.plugins.<amount>`. Here's an example in LuckPerms:
|
||||
The next thing you'll wanna do is to give all the groups that have `playerservers.manage` permission a new permission as following: `playerservers.plugins.<amount>`. Here's an example in LuckPerms:
|
||||
|
||||
```yaml
|
||||
/lp group default permission set playerserver.plugins.10
|
||||
/lp group default permission set playerservers.plugins.10
|
||||
```
|
||||
|
||||
If your groups have parent permission, the plugin will give the player the largest possible amount of plugins by their permission.
|
||||
|
@ -24,7 +24,7 @@ In order to begin, you'll need to change a few config options. Make sure your cp
|
||||
cpu-limiting:
|
||||
# Only for docker-based servers,
|
||||
# should we use permissions for cpu management? If set to true, you MUST give
|
||||
# your players permission playerserver.cpu.<amount> (ex: playerserver.cpu.1)
|
||||
# your players permission playerservers.cpu.<amount> (ex: playerserver.cpu.1)
|
||||
# or, else, the command will be blocked, and player will not be able to create
|
||||
# the server. If set to false, everyone will have cpu-per-server amount of CPU.
|
||||
use-permissions: false
|
||||
@ -35,10 +35,10 @@ cpu-limiting:
|
||||
|
||||
By enabling use-permissions, the plugin will ignore cpu-per-server option and will use permission-based CPU management system.
|
||||
|
||||
The next thing you'll wanna do is to give all the groups that have `playerserver.manage` permission a new permission as following: `playerserver.cpu.<cpu as percentage>`. Here's an example in LuckPerms:
|
||||
The next thing you'll wanna do is to give all the groups that have `playerservers.manage` permission a new permission as following: `playerservers.cpu.<cpu as percentage>`. Here's an example in LuckPerms:
|
||||
|
||||
```yaml
|
||||
/lp group default permission set playerserver.ram.100
|
||||
/lp group default permission set playerservers.ram.100
|
||||
```
|
||||
|
||||
In the following example, we gave the role default ability to create a server with 1 CPU core.
|
||||
|
@ -6,7 +6,7 @@ description: Learn how to make a permission-based RAM system for your players
|
||||
|
||||
## Introduction
|
||||
|
||||
We know that making a permission-based RAM system is a crucial to our customers and could be greately used for online stores in order for them to earn money for Ranks & Perks, so we've implemented a permission-based RAM system. In this tutorial, you'll learn how to configure it for your needs.
|
||||
We know that making a permission-based RAM system is a crucial to our customers and could be greatly used for online stores in order for them to earn money for Ranks & Perks, so we've implemented a permission-based RAM system. In this tutorial, you'll learn how to configure it for your needs.
|
||||
|
||||
## Tutorial
|
||||
|
||||
@ -15,7 +15,7 @@ In order to begin, you'll need to change a few config options. Make sure your ra
|
||||
```yaml
|
||||
ram-limiting:
|
||||
# Should we use permissions for ram management? If set to true, you MUST give
|
||||
# your players permission playerserver.ram.<amount> (ex: playerserver.ram.512)
|
||||
# your players permission playerservers.ram.<amount> (ex: playerserver.ram.512)
|
||||
# or, else, the command will be blocked, and player will not be able to create
|
||||
# the server. If set to false, everyone will have ram-per-server amount of RAM.
|
||||
use-permissions: true
|
||||
@ -26,8 +26,8 @@ ram-limiting:
|
||||
|
||||
By enabling use-permissions, the plugin will ignore ram-per-server option and will use permission-based RAM management system.
|
||||
|
||||
The next thing you'll wanna do is to give all the groups that have `playerserver.manage` permission a new permission as following: `playerserver.ram.<amount in MB>`. Here's an example in LuckPerms:
|
||||
The next thing you'll wanna do is to give all the groups that have `playerservers.manage` permission a new permission as following: `playerservers.ram.<amount in MB>`. Here's an example in LuckPerms:
|
||||
|
||||
```yaml
|
||||
/lp group default permission set playerserver.ram.512
|
||||
/lp group default permission set playerservers.ram.512
|
||||
```
|
||||
|
Loading…
Reference in New Issue
Block a user