CloudNet | The Cloud Network Environment Technology 3.0.0 Tsunami PRE-3

The alternative Minecraft Java and Bedrock server management and wrapper application

  1. Dytanic
    Tested Minecraft Versions:
    • 1.7
    • 1.8
    • 1.9
    • 1.10
    • 1.11
    • 1.12
    • 1.13
    Languages Supported:

    What is CloudNet Tsunami?

    CloudNet is an alternative application that can dynamically and easy deploy Minecraft oriented software. It should greatly simplify the work and the technical processes within a Minecraft server network or with standalone servers. The program should be the basis for a Minecraft network. With a very extensive API and a very modular architecture, the program should be easily extensible in all its capabilities. It should be a solution to the most creative ideas that brighten our Minecraft world. From minigame networks, CityBuild servers to private servers with CloudNet is the work low. If it needs to be developed for CloudNet, it will provide an API (Driver) that can be used to develop Bukkit / Sponge / Nukkit plugins or to develop modules to extend the core system. The application wrapper for the JVM allows support for a wide variety of Minecraft server software and allows direct inclusion of the API to retain it throughout the lifetime of the application.

    CloudNet is the next generation of Minecraft Java and Bedrock cloud systems

    CloudNet is currently stable. You can use it, for a productive network.

    What about CloudNet 2.X?

    CloudNet 2.X is available on the following Github page and will be updated and corrected until 21.5.2019.


    Jenkins CI:

    Unique features
    • The first Minecraft Bedrock edition "cloud system", which supports NukkitX, GoMint and ProxProx to make a full Bedrock edition network
    • Supports as first public "Minecraft cloud system" Velocity proxy server
    • Supports as first public "Minecraft cloud system" default Vanilla minecraft server
    • The first public "Minecraft cloud system" which works in a high available cluster topology
    • Supports as first public "Minecraft cloud system" the SpongeAPI

    • Plug&Play
    • Lightweight runtime launcher for multiple versions or easy developing on CloudNet
    • Installer of dependencies
    • Module system with default modules
    • User management system with roles
    • Easy server management with simple commands
    • Tasks to classify the services
    • Internal database system based on H2
    • Multi group and configuration
    • Dynamic Template Storage System
    • Dynamic Deployment System
    • Dynamic File inclusions for services with HTTP/HTTPS support
    • Static services support for Projects like CityBuild or Vanilla
    • Live updating and working in a cluster
    • Smart service instance deployments in cluster
    • New non blocking service console log caching without BungeeCord timeouts and infinity console streams
    • A fast HTTP/HTTPS server
    • A RESTful API
    • SSL/TLS support for security connections between the nodes in cluster or between the services and the node with or none own certificates
    • Multi root support and synchronizing in a network cluster
    • Support for Minecraft vanilla 1.0+
    • Application support for Nukkit Project 1.0+ for Bedrock Edition 1.7
    • Application support for Bukkit based Minecraft 1.5.2+ (Craftbukkit, Spigot, PaperSpigot, Torch)
    • Application support for Sponge based Minecraft servers with the SpongeAPI 7.0.0+
    • Application support for BungeeCord proxy server and forks for MC 1.5.2+
    • Application support for GlowStone minecraft server for MC 1.8.9+
    • Application support for Velocity proxy server
    • Application support for ProxProx Bedrock Edition server
    • Application support for GoMint as Minecraft Bedrock Edition server software
    • A every powerful API for
      asynchronously programming or
      synchronously programming
    • A Bridge module, which includes the basics for the Bukkit, Sponge, BungeeCord and Nukkit API and for BungeeCord a /cloudnet command to dispatch the console of CloudNet ingame
    • BungeeCord exploit protection with the Bridge Module for BungeeCord MC 1.5.2+
    • Random Hub and /hub command with the Bridge Module for BungeeCord MC 1.5.2+
    • /cloudnet command which dispatch the console of CloudNet Ingame for BungeeCord MC 1.5.2+
    • A live, ingame, sorted signs system for Bukkit and Sponge with a dynamic animation and configuration for each group.
    • A SyncProxy module, which include the synchronization between two or more BungeeCord services in one group.
    • Motd layout configuration and synchronizing between Proxys with SyncProxy module
    • Animated Tablist configuration with SyncProxy module
    • - A Smart module for advanced configurations and automatic task management
    • A Cloudflare module for dynamic adding and removing of DNS records for multi BungeeCord services
    • A Report module Easily create reports to hear the services or node in the cluster and provide easy support.
    • A Storage FTP/FTPS module to transport templates from an external server via FTP / FTPS
    • A MySQL/MariaDB database support module as alternative central database for CloudNet data by other modules
    • A Permissions Module which integrate the CloudNet user permissions system into the services plugin managers
    • Memory management protection
    • CPU management protection


    • Java 8 JRE (alt. 10 or 11)
    • 128MB JVM Heap size
    • 2GB DDR3 Memory
    • 2 virtual cores
    • Internet connection
    • 10 minutes read and employment time
    • Handling capacity with Craftbukkit and BungeeCord
    • Java 8 JRE
    • 512MB JVM Heap size
    • 8GB DDR3 Memory
    • 2-4 virtual cores
    • Internet connection
    • 1h read and employment time
    • Handling capacity with Craftbukkit, Spigot, BungeeCord (Velocity, Nukkit, GoMint)



    CloudNet should be started via the following script via Shell or a shell script.

    Code (Text):

    java -XX:+UseG1GC -XX:MaxGCPauseMillis=50 -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -XX:+UseCompressedOops -Xmx512m -Xms256m -jar launcher.jar

    The launcher should install the application files, then the dependencies. If it is finshed, it will run the application itself.
    For each version, this preparation is done dynamically.

    After the installation has been completed, you can now set up a simple network for Minecraft.
    This is shown for the Minecraft version 1.8.8 with spigot as an example and BungeeCord

    In this case the tasks "lobby" as **minecraft server** service, "bungee"
    as **BungeeCord** service and a "test" task are created with the "tasks" command.

    Code (Text):

    tasks create task Lobby minecraft_server
    tasks create task Bungee bungeecord
    tasks create task Test minecraft_server
    To do this, the command creates a local template for each task with the task prefix and the name "default".

    As an an example:

    For each task whose environment the configuration files have already been prepared.
    With the command "local-template list" you can see all local templates.
    For each of these tasks, an additional **group** has been created so that you can easily associate with the extensions.

    You can either use the commands that automatically install Jar Archive, or the programs in the respective template directory the "spigot.jar" or "bungee.jar"

    Code (Text):
    local-template install minecraft_server
    local-template install Lobby default minecraft_server spigot-1.8.8
    local-template install Test default minecraft_server spigot-1.8.8
    local-template install bungeecord
    local-template install Bungee default bungeecord default
    With the "tasks" command or in the /local/tasks.json file you can configure the tasks and groups, and add templates, deployments and inlcusions there.
    If you use the configuration file, you should use the "reload config" command.

    With the "create" command, you can now manually create a service based on a task.
    You can also create custom services with "create new".
    Code (Text):
    create by Bungee 1
    create by Lobby 1

    service Bungee-1 start
    service Lobby-1 start
    The "service" command allows the administration of the created service.
    The manual stop, start, restart and inform about a service in the cluster can invoke with this command.

    If the bridge module is installed, you can join the pre-configuration directly to the lobby server via the BungeeCord server.

    The further equipment is up to you!
    Have fun!


    Dytanic (Developer) 3.0.0 Tsunami PRE [German]

    Pume 3.0.0 Tsunami PRE [GERMAN] (Recommended)

    TheMeinerLP Livestream 3.0.0 Tsunami PRE [GERMAN]


    The launcher is the program that enables the preparation of the actual application. It can automatically update
    CloudNet in release versions. He also manages the versions and dependencies of a version. This prevents redundancy
    of libraries and increases the startup speed of new versions. Furthermore, the standard modules can always be updated for the current launcher version.
    The launcher interprets the .cnl files to provide all major system configurations for the application. Opposite the config.json is the launcher.cnl file.
    The launcher.cnl configuration, are also provided as system properties during the actual runtime of the application.

    The version, which is by default set to "default", can be switched to a specific version. For example, on the one in the folder launcher / versions.

    Any Minecraft / Proxy server etc. that can be created by CloudNet is considered a service of everything on the network.
    This state is so abstracted that with CloudNet it is easy to integrate many programs like Nukkit, Glowstone, Velocity or others.
    The fact that the services are created via an application wrapper, and then the actual programs are loaded at runtime, resulting in a high
    degree of preparation and integration. The services are also not distinguished, except for the types of service,
    to allow customized configurations, such as setting the port for the server or changing certain configurations.

    Services can be created with CloudNet in many different ways, including the "create" command.
    Every service is based on a task. For example, if the "create" command creates a completely new server named "test",
    it will be based on the task "test" and will also receive the task service id 1. "test-1" would be the first service from the task "test".

    Then this would be about a task configuration that you can create and provides a rough configuration form for a service.

    The services are always temporary, but there is also the configuration "afterDeleteOnStop", which aggravates the
    factor so that the service is automatically deleted when it stops. Otherwise,
    the services can be started, stopped and changed as desired and new templates added or inclusions of web pages.

    Saved, these services can be called "deployments". They allow you to write back the entire service to a TemplateStorage service such as Local

    Tasks are activities CloudNet should perform.
    Each service is based on one of these tasks. Each task can own groups. Each task forms the "skeleton"
    of a service and its inclusions, templates, deployments, group affiliation etc.

    Tasks are also used to identify the individual services running on the network.
    However, apart from the type of service, they do not exactly describe which properties the individual application type possesses.

    Tasks can be managed with the "tasks" command in CloudNet or in the "tasks.json" in the "local/" directory

    Code (Text):
    tasks create task Lobby minecraft_server[/COLOR][/SIZE][/COLOR][/SIZE][/COLOR][/SIZE][/COLOR]
    [COLOR=#b30059][SIZE=4][COLOR=#000000][SIZE=4][COLOR=#b30059][SIZE=4][COLOR=#000000]tasks create task Bungee bungeecord
    tasks create task LobbyNukkit nukkit
    tasks create task MapServer glowstone
    Multi groups

    The groups are intended to summarize services and tasks. Each service can belong to one task and several groups.
    Groups can add their own extra settings to the tasks as well as other groups, inclusions, deployments, templates.

    As an example, there is the group lobby, the task "Lobby" and the task "PremiumLobby". Both tasks have membership of the group "Lobby".
    In its configuration, the Lobby group determines that all tasks belonging to the "Lobby" group should also retrieve the templates local
    with the prefix/folder "Lobby" and the name "all" and install them in the service.

    Groups can be used by developers to extend the range of possibilities and abstraction of tasks.
    There may be different types of tasks in a group, such as "Lobby" and "Bungee" in the "Global" group
    Template Storage

    With the API, CloudNet allows the use of multiple template storage services to retrieve or deploy templates.
    By default, the core of CloudNet brings the "local" template storage service.

    Every service template that can be configured has a storage, ie the service from which the data is to be retrieved or transmitted.
    The prefix is to set the namespace of the template in order to combine several templates within one namespace.
    The name is the actual name of the template.
    Code (Text):
            {  "prefix": "Lobby",    "name": "default",   "storage": "local" }

    For each task, which is created with the "tasks" command, a
    local template is also created. The local templates are always synchronized in the cluster.

    Service management

    CloudNet, provides very extensive features to manage the services in the cluster.
    With the "create" command the services can be created manually.

    Code (Text):

    create new Lobby 1 minecraft_server templates=local:Lobby/default afterDeleteOnStop=false groups=Lobby,Global memory=356


    create by Lobby 1
    With the "--start" parameter, the registered and prepared services can automatically start automatically.
    The created services can be managed in the cluster via the "service" command.

    Show all services and some informations from one Task
    Code (Text):

    service list task=Lobby
    Displayed, via the current information snapshots, you can via the UUID of the name. It is enough to write only a part of the respective one.
    The info parameter also displays the plug-in and module information, which is transmitted via the bridge module in JSON.
    Code (Text):

    service Lobby-1
    service 32bc1b46-a8ac-40cf-9fea-208984c61c7e

    service Lobby-1 info
    service 32bc1b46-a8ac-40cf-9fea-208984c61c7e info
    Each service can be easily started, stopped, restarted and deleted.
    Code (Text):

    service Lobb start
    service Lobby stop
    service Lobby-1 stop --force //For
    service 32bc delete
    service L restart
    You can run a started service with the "command" parameter in the console.
    Code (Text):

    service Lobby-1 command say Hello Server!
    In addition, you can additionally reboot for a server, adding templates and inclusions to a service.
    And if the service is deleted, you can add additional deployments.
    Code (Text):

    service Lobby-1 add template local Lobby global
    service Lobby-1 add inclusion plugins/essentials.jar
    service Lobby-1 restart
    service Lobby-1 add deployment local Lobby SavedLobby
    You can make persistable (static) services from one task to add a deployment
    Code (Text):
    tasks task Lobby add deployment local Lobby default
    With the "screen" command, you allow the node to output the console output that is stored between and is output live from the application
    Code (Text):
    screen Lobby-1
    Working with multiple nodes in a Cluster

    The instances of CloudNet, also called Nodes, can be easily connected.
    This allows tasks, groups, and local templates to synchronize with the network and distribute
    the services to each node. With appropriate configuration, this can significantly increase the
    overall resilience of the network. It also allows easy task distribution.

    Each cluster has its own clusterId, which can be found in config.json.
    It is important that all nodes in the cluster have the same "clusterId" in their configuration file.

    All nodes in the network must be interconnected. There are no direct master / slave behaviors,
    but only the rule that the node that connects to another node
    gets the information from the already existing node and updates it. (Except the cluster configuration)

    Add a node in the cluster:

    The addition of a node can either be done at runtime, or within the configuration file.

    Code (Text):
    cluster add e760a2c3 1411
    or in the config.json

    Code (Text):
      "cluster": {
        "clusterId": "d5e96e6d-ce98-43fc-a33d-a456eeb43561",
        "nodes": [
            "uniqueId": "e760a2c3",
            "listeners": [
                "host": "",
                "port": 1411
            "properties": {}
    The node with the specified name must not be online at the time, because the latter must then connect,
    and then, as the client of the online node, first retrieve all information, such as tasks, groups, templates,
    node information, ServiceInfoSnapshots. It is important that the initial setup, the node is online, which has the most
    up-to-date information. At runtime, where all nodes are online, in the core system of CloudNet any
    information like the one mentioned above should be in sync.
    All new ones will receive the information and update their own.

    Update manual information:

    With the command "cluster push" the Local Templates, Tasks and Groups, the bsp.
    via configuration file or template changes have just been changed. Manually updated and synchronized on the network.

    Code (Text):
    cluster push templates
    cluster push tasks
    cluster push groups
    Remove a node in cluster:

    This operation should be done manually. As with the addition, this must be configured for each node, but here in the config.json.

    The JSON object to the node to be removed just needs to be removed. Then should also with the command

    Code (Text):
    reload confirm
    Also the connection to the node will be closed.
    It is recommended to restart the node.

    How do modules work in the cluster?

    Modules do not have the duty to work in a computer network. The default modules of CloudNet are,
    with a few exceptions, designed like the Cloudflare Module for the use of multiple nodes. Important here is that
    these modules are then installed individually on each node. This process is not automated because
    there is a duty with the functionality to work in the cluster. If needed, the appropriate developer,
    such a function, can install it via the API itself. ;)

    How does the API work with multiple nodes?

    CloudNet's Driver API is designed to use a single and a cluster. As a result, changes in the
    plugin development are rarely necessary. In module development, most areas of the CloudNet application
    beyond the Driver API are designed to automatically update the data. If necessary, individual areas can be expanded.

    Default modules

    Here is an introduction to the modules. These modules are the standard equipment.
    These modules include the advanced functionality of CloudNet. They should be a
    support for a Minecraft network to save a lot of their own technical developments or reduce the effort.

    All standard modules that have a configuration have a config.json in each module's name folder.

    The bridge module is the core of the modules, which are also plugins for the service. In addition it forms the connection of the Minecraft servers to the proxy server and a Random Hub system with multiple fallbacks.
    To protect against BungeeCord explode, this module also has extra login protection for the offline server.
    It provides the ingame console dispatcher for BungeeCord with the / cloudnet (/ cloud) command.
    The permission for this is "cloudnet.command.cloudnet"
    This module currently supports the PluginManagers from Nukkit, Sponge, Bukkit and BungeeCord.

    It is recommended to keep the module for the network,
    as it is supported by the amount of information and basic support functions with the
    PluginManager of the services and for the own development of plugins and / or modules
    The sign system has a sorted animated, live updating sign system, depending on the order of occupation.
    The tags can even be targeted to specific groups with a template path limitation.
    The services as well as the sign system itself need the CloudNet bridge module, so
    that the information for the presentation is available. Otherwise, the signs would
    only show the servers as the starting phase.
    With the /cloudsign command, the signs can be set or deleted while watching one of them.

    Here is a list of patterns for the sign layout

    Code (Text):
    %task% - Name of task %task_id% - Current id from one task[/SIZE][/SIZE][/COLOR][/COLOR]
    [COLOR=#b30059][COLOR=#000000][SIZE=6][SIZE=4]%group% - The group which the sign has target
    %name% - The readable Name of the service like "BedWars-1"
    %uuid% - The first characters of the service uniqueId
    %node% - The node from the service
    %environment% - The environment type of the service which is configured
    %life_cycle% - The current life_cycle type
    %runtime% - The runtime process type
    %port% - The current configured port of the service
    %cpu_usage% - The current CPU usage of the service
    %threads% - The current Thread count
    %online% - Is the service online or not from the "Online" property in Bridge-Module
    %online_players% - The current online count of the service
    %max_players% - The max players size from the service
    %motd% - The Motd of the service or the Text of the CloudNet-BridgeAPI
    %extra% - The extra string text by the CloudNet-Bridge API
    %state% - The state string text by the CloudNet-Bridge API
    %version% - The current version of the service
    %whitelist% - Request if the whitelist enabled or not[/SIZE]
    The SyncProxy module is responsible for the pure representation of the motd and the tab list in order to
    synchronize proxy services within a group. She also has a maintenance mode with a whitelist on it.
    Above all, it is interesting when it comes to the use of multiple proxy services to distribute the players there.

    Motd Patterns:
    Code (Text):
    %proxy% - The current proxy service name[/SIZE][/SIZE][/COLOR][/COLOR][/SIZE]
    [SIZE=6][COLOR=#b30059][COLOR=#000000][SIZE=6][SIZE=4]%proxy_uniqueId% - The current proxy service uniqueId
    %task% - the current task name of the current proxy
    %node% - the node uniqueId of the proxy

    Tablist Patterns:
    Code (Text):
    %proxy% - The current proxy service name[/SIZE][/SIZE][/COLOR][/COLOR][/SIZE]
    [SIZE=6][COLOR=#b30059][COLOR=#000000][SIZE=6][SIZE=4]%proxy_uniqueId% - The current proxy service uniqueId
    %server% - The server name which the player is connected
    %online_players% - The current proxy online count
    %max_players% - The max player size, which is configured is
    %proxy_task_name% - The task from the proxy, which the player is connected
    %name% - Name of the player which get the tab list
    The Smart Module adds configurations to the actual Task Configurations,
    plus additional customizations adapted to the CloudNet Bridge Module.
    Through this, processes that exist in CloudNet can be optimized for a
    MiniGame network so that the need for game servers is optimally adapted to those of the players.
    The Cloudflare Module allows automatic entry of Domain DNSRecords for larger required network capacities.
    These can be made from any type of application, from bungee cord to normal vanilla servers, the group sets the tone.
    For the configuration you need a domain and an account at the provider
    Several domains with different users etc. can be managed, even for the same groups.
    You need the email, the API key from the account (not the global API key!), The ZoneId found on the domain's dashboard page.

    The "@" wildcard in the "sub" configuration of a group determines that it does not become
    a subdomain that owns a third-level domain, but only a second-level domain.

    The configuration must be set up in the cluster at each node individually, so that one can avoid unintentional entries such as
    nodes that are within an internal LAN and can only be reached via specific ports or proxy servers.
    The module allows a TemplateStorage to connect to a remote server with either FTP or FTPS. For this, the current file path is still required in the configuration. The structure of the templates is similar to that of the Local Template System, except that the default storage name is "ftp". However, this can be changed in the config.json of this module. Basically, the module needs a proper basic configuration to use it. The use of the template storage "ftp" could lead to immediate errors without previous configuration.


    Java documentation

    CloudNet will be full documentated in the RELEASE version of 3.0.0


    Code (Text):

    <!--- Repository --->

    <!--  cloudnet application -->

    <!--  cloudnet driver for modules -->

    <!--  cloudnet wrapper for plugins -->

    <!--  cloudnet bridge module for plugins and modules -->

    <!--  cloudnet signs module for plugins and modules -->

    <!--  cloudnet syncproxy module for plugins and modules -->

    <!--  cloudnet cloudperms module for plugins and modules -->







    PS: I know, this is hard to learn about a new application, but give the application a hour of time and try some things.

Recent Reviews

  1. aandree
    Version: 3.0.0 Tsunami PRE-3
    Das CloudSystem ist wirklich exzellent und alles funktioniert reibungslos, jedoch weiß ich nicht wie ich einen normalen Server der nicht nach einem Template gestartet wird erstellt. Der z.B. für einen CityBuild gedacht ist. Wäre nett wenn du mir dabei weiterhelfen kannst.

    Ansonsten 1A

  2. Maikiboy2000
    Version: 3.0.0 Tsunami PRE-3
    Hey könnten Sie bitte noch die Funktion einbauen das man auch Sponge Forge verwenden kann als normale Server Version?

    Da ich gerne auf einen normalen Server Mods + Plugins laufen lassen möchte.

    Aber ansonsten ist die neue Cloud sehr gut gelungen.

    Mit Freundlichen Grüßen: Maik
  3. ProxieTV
    Version: 3.0.0 Tsunami PRE-3
    Das CloudSystem ist echt erste Klasse und funktioniert - trotz das es noch in der PRE-Phase ist - ziemlich gut.

    Das einzige was recht schade ist, ist dass zur Zeit recht selten neue Updates erscheinen, in denen die wenigen Bugs gefixt werden. So wartet meinerseits aktuell ein großes Builder Team , welches erst weiterbauen kann wenn man über das ServiceInfoSnapshot Daten abspeichern kann. D.h währe es echt super, wenn bald ein Update erscheint, wo z.B das PropertiesJsonDocument nicht beim Serverstart resettet wird.

    Nun noch ein kleiner Hinweis für "simplenametags": Ab der aktuellen Version 1.13 reicht es für den Tabnamen nicht einfach nur Prefix und Suffix dem Team zu setzen, nun muss nähmlich auch die Color gesetzt werden, in welcher der name dann angezeigt wird (sonst wird zwar der prefix richtig angezeigt, aber der spielername ist weiß). Diese Color müsste man dan einfach auf den letzten ColorCode aus dem Prefix setzen.

    Da ich mich schon relativ tiefgründig mit dem System beschäftige und es auch aktiv verwende, würde ich mich über eine FA über Discord (Florian | ProxieTV#9455) freuen, damit ich gerade in der PRE-Phase wichtige Sachen, die sich nicht so gut auf dem Discord Server klären lassen direkt mit dir kommunizieren kann.

    Mach weiter so!
    Gruß, Florian
    1. Dytanic
      Author's Response
      Guten Tag,

      Danke für diese lange, ausführliche Review, wo du sowohl kritik, bugs und verbesserungswünsche Erwähnt hast. Habe diese zur Kenntnis genommen und werde entsprechend eine Antwort, bzw. einen Bug fix anfertigen. Es wurden bereits einige Fehler behoben und werden es immernoch. Habe auf Discord bsp. schon eine Grenze gemacht bei den Suggestions and Bug-Reports die Rein kamen.

      Bezüglich, dessen, dass man im ServiceInfoSnapshot nichts speichern kann, gibt es schon seid beginn an, eine Schnittstelle für Entwickler, auf dessen auch einige Module basieren. Mithilfe der ServiceInfoSnapshotConfigureEvent Klasse ist es unter anderem möglich die Properties für das Fertige ServiceInfoSnapshot Objekt hinzuzufügen.

      Mit der 1.13 Geschichte wird demnächst noch was zusätzlich als Property bei den Permission Gruppen hinzugefügt.

      Mit freundlichen Grüßen
  4. Lukas1606_yt_lp
    Version: 3.0.0 Tsunami PRE-3
    Excellent! benutz ich auch für meinen Server und alles läuft reibungslos danke Dytanic für dieses Cloud-System
  5. Jankooo
    Version: 3.0.0 Tsunami PRE-3
    1A Sahnespitze!
    Super Support, gutes System einfach nur Top weiter so!

    Ideen ->
    MobJoin (CN 2.0)
    Wieder Chat-System implentieren!

    Sonst Supi
    Nur zu empfehlen!
    1. Dytanic
      Author's Response
      Guten Tag,

      vielen Dank für diese Review!

      Bezüglich deiner Ideen wie die ServerMobs und das Chat System sind sicherlich nicht auszuschließen.

      Es waren/sind in der 2.X 2 relevante Funktionen.

  6. NokonHD
    Version: 3.0.0 Tsunami PRE-3
    Wenn man sich erstmal ans neue System gewöhnt hat seht nice ;)
    Allerdings vermisse ich einige Funktionen wie der Server Mobs oder Perms um volle Server beizutreten.
    ansonsten super teil danke dir weiter so!
    1. Dytanic
      Author's Response
      Guten Tag,

      vielen lieben Dank für die Review. Verstehe gut, dass es Zeit benötigt sich in die neue Version der Software einzufinden.

      Es gab jedoch bisher keine permission um volle Server zu betreten.

      Aber was noch nicht ist, kann noch werden!

      Mit freundlichen Grüßen
  7. denJakob
    Version: 3.0.0 Tsunami PRE-3
    Gutes, sehr zuverlässiges CloudSystem. Ich bin schon seit ca. einem Jahr dabei und finde die Entwicklung von CloudNet echt heftig!
    Dazu ist alles gut und verständlich auf dieser Seite erklärt, so dass einer schnellen Einrichtung nichts im Wege steht. Dazu gibt es so eine große Funktionsbreite, bei der kein anderes, mir bekanntes, CloudSystem mithalten kann.

    Mach weiter so :D

    ~ denJakob
  8. wizardHD
    Version: 3.0.0 Tsunami PRE-3
    gutes system. wie kann ich meinen Lobby server als template sichern?
    Also früher ging es ja anders?
    1. Dytanic
      Author's Response
      Guten Tag,

      vielen Dank für diese 5 Sterne Bewertung!

      Um auf deine erste Frage zu antworten kann man mithilfe des Konsolen Befehls auszuführen, dann den Service löschen:

      "service Lobby-1 add deployment local Lobby default"

      Würde bitten beim nächsten mal, in einer privaten Konversation, unter dem Diskussionsbereich oder auf dem Discord Server support fragen zu stellen

      Mit freundlichen Grüßen
  9. TomasGeilo
    Version: 3.0.0 Tsunami PRE-3
    Hallo Tarek,
    also ich finde dein CloudSystem so heftig und geil.
    Könntest du noch ein BungeeSystem mit hinein integrieren?
    Das wäre so unglaublich geil von dir :D

    1. Dytanic
      Author's Response
      Guten Tag,

      ist schön zu lesen, dass dir das Programm zusagt.
      Könnten sie beim nächsten mal oder demnächst diese und folgende Vorschläge zur Verbesserung oder Erweiterung der Software präziser und genauer Erklärt in einer privaten SpigotMC Konversation oder auf dem CloudNet Discord Server schreiben. Damit man gegebenenfalls darüber schreiben und diskutieren kann.

  10. Craftoncu
    Version: 3.0.0 Tsunami PRE-2

    danke für dieses System. Ich glaube nicht, das du gedacht hattest, das es 40.000 Netzwerke nutzen würden. Es passt einfach alles! Vom System bis zur Community! Hör damit ja nicht auf!

    PS: Nimm meine FA auf Discord wieder an du Sack ;)

    Daniel | Craftoncu
    (ehem. CloudNet-Mod)
    1. Dytanic
      Author's Response
      Hey Craftoncu!

      Vielen Dank für diese Review!

      Habe dir eine Freundschaftsanfrage gesendet, da ich selbe keine mehr annehmen lasse und vor kurzem extrem aussortiert habe.

      Mit freundlichen Grüßen