Skip to content

Latest commit

 

History

History
56 lines (37 loc) · 4.47 KB

Installation.md

File metadata and controls

56 lines (37 loc) · 4.47 KB

Installation

Flier requires Spigot 1.9 or later. Earlier versions won't be supported because they lack Elytras. No other plugins are required to run it, although there are some optionals integrations.

To install Flier on your server simply place the Flier.jar file in your plugins directory and restart/reload the server. The plugin will generate its default configuration files. In case you want to immediately set up the example game you need to review the files, set all locations to correct values and uncomment the default lobby in lobbies.yml. If there are any errors they will be displayed in the console.

Read the documentation at least briefly before creating your own games.

Server setup

Flier includes a lot of flying around at high speeds. This means that your server will have to continuously load and unload chunks and send them to the players. Additionally, the players will want to see a little bit more that a second's worth of terrain, so you'll want to increase the view distance. That puts even more strain on the server.

My first advice is not to use CraftBukkit. It's performance is similar to vanilla Minecraft server, which is bad. Choosing Spigot instead will not only make Flier 100% compatible, it will also improve your performance.

Sadly, even Spigot will face problems when rapidly loading/unloading chunks - it may happen more quickly than Java can clean its memory, which leads to OutOfMemory crashes. The solution is PaperSpigot. It keeps the chunks loaded for a brief time, so despite using a little bit more memory, the server doesn't have to clean it up so often, thus reducing memory usage.

Having a fast CPU, RAM and SSD will also help, but that's more expensive than changing setting mentioned above.

Since Spigot/Paper have a configurable (but limited) range of displaying entites, it'd be good to increase that to at least 256 blocks. Minecraft client probably won't display farther entities at all, so that's a good server-side limit. Thanks to that players will be able to see each other (and entity based bonuses) from greater distances.

How to read this documentation

Every chapter covers one or more objects in Flier. Example of these objects are Lobbies, Games, Actions, Engines etc. Each object is defined in its file. The appropriate chapter describes how to define such object:

(It's a good idea to look for example at the Game chapter to see described parts.)

  1. Firstly, there's always an explanation of what it is and how it generally relates to other things.
  2. Next is the schema of the configuration, showing all options which apply to all those objects. This also shows what type are the values required in these options.
  3. After that there's an explanation of what each option does, whenever it's required or optional, and if so, what's the default value. You must always define required values, and if you skip options with default value, it will be used. Skipping optional settings is also allowed.
  4. Some objects have subtypes (for example deathmatch is a subtype of the game). In that case subtypes are described below the general object description.
  5. Below the name of the subtype there's always a keyword. Use this keyword in the type option of the general object to tell Flier which subtype you want to define.
  6. Under the keyword there's the subtype description.
  7. Next is the schema of configuration of that object type, just like that of the general object.
  8. This schema usually contains a line saying [default object settings] - this should be replaced by settings shown in point 2.
  9. Below the subtype schema there's explanation of its options, just like in point 3.

If you have any problem with decrypting the documentation structure please look at the default files generated by the plugin and compare them to what you see here.

Translatable texts

Flier is integrated with [BetonLangAPI] plugin. Thanks to that plugin it display every text to the player in his chosen language. When you see a data type [translatable text] then you can enter the name of the string from messages.yml file there, just prefix it with $ character.

For example if you have this in your messages.yml:

en:
  [...]
  custom:
    concrete: Concrete
pl:
  [...]
  custom:
    concrete: Beton

you can use $custom.concrete as your translatable text. This way you can create games where everything, from hit messages to class names to item descriptions is translatable to players' chosen languages.