Standalone TimoCloud - The most intelligent cloud system 6.2.1

Powerful open source server management system

  1. TimoCrafter updated TimoCloud - The most efficient cloud system with a new update entry:

    [5.0.5] Lots of bug fixes

    Read the rest of this update entry...
  2. TimoCrafter updated TimoCloud - The most efficient cloud system with a new update entry:

    [5.0.6] API Data available right after TimoCloud loaded

    Read the rest of this update entry...
  3. TimoCrafter updated TimoCloud - The most efficient cloud system with a new update entry:

    [5.1.0] Introduce CloudFlare RoundRobin DNS + fix a few bugs

    Read the rest of this update entry...
  4. @TimoCrafter Really curious to try this out.
    Lets say you want to run minigames, anyway to autospawn servers when you need new ones? And when they are idle for long do they auto shut down? Ofcourse could add my own code for that
    Would it be possible to easily implemented clans/guilds with this system?
    If I have a few static servers with lets say Multicraft for the Bungeecords, would I be able to use those with TimoCloud?
    Thanks for sharing man, looks very promising!
  5. Hi,
    Servers can be started automatically depending on demand. Proxies will be stopped automatically if they are empty and not needed, but servers don‘t need to: If 4 servers are started because 3 are ingame and 1 is ready, these 3 will stop anyway when the game is finished, and the one server will stay because you specified it has needed.

    TimoCloud has a really powerful API, so you can easily use it with your own systems.

    You can have static proxies and servers as well, yes.

    Kind regards,
    • Friendly Friendly x 1
  6. Thanks for your response @TimoCrafter
    Started on implementing your code.
    I was wondering if there where certain features which I overlooked:
    - Possibility to send a player a message using the PlayerObject instance
    - Possibility to easily add extra fields to PlayerObject like party id/guild id? (I'm assuming I need to add this to every implementation class?)
    - Possibilitiy to add other data (I.E. A party class) which is available on every bukkit server?
    - Get the best server of a group, any pre defined Comperators? (I.E. I want Bedwars servers filled and not spread out over all the servers)
    - Get the best lobby server, aka spreading the players out over all lobby servers

    Is this approach right:
    Currently I'm getting all Bedwars servers of the group in the Bukkit side, then comparing them to get the best server and would send them to that one? Would you advice something else with your apis?

    Do you strongly discourage me to use the sockets itself for lets say sending the player a message to the proper server?
  7. Hey,
    The current API is mostly for getting all the data of all instances on the whole network in real-time, plus an event API. I am planning to add a properties Map to the ServerObject class, and it‘s probably not a bad idea to do that for ProxyObject and PlayerObject as well.

    The default comparator sorts the servers by the number behind the ‚-‚. TimoCloud does have a lobby system implemented in BungeeCord, with 3 algorithms to choose from. I think it‘s not hard to sort the servers by a field like player count and everyone can do that himself.

    Now the last, but biggest point: Interacting with players/sockets via the API. That‘s not easy to discuss. Let‘s take the players first. If I implement a sendMessage method, why not add a teleport method too? Or a kick method? Should I implement the whole Bukkit API? It‘s hard to find a good way out here. But regarding your party system: Why not let the server/proxy the player is connected to perform the actions?

    But that leads us to the next point: Communication. As you might know, TimoCloud has a pretty nice communication system. Send a message to a target address, and it will go through several steps in the pipeline, and if it‘s not being processed by the core, it will be redirected to the TimoCloudBukkit/Bungee instance on the target itself. Keeping this in mind, it‘s not that hard to implement a communication API. The harder question is how this API should be designed. I would personally like some sort of storage classes which are automatically synchronized over the whole network, including it‘s method calls. That means, for example:
    ...could call a method on every PartyManager instance over the whole network. Of course, you‘d also have to synchronize data structures, like Maps and all the other fields a class might have.
    This would need a lot of reflection and I don‘t know yet in how far this is possible, but what do you think?

    Kind regards,
  8. Hey that is a lot of food for thought haha.

    Its basicly going to be an endless thing of features to be added. But if the base is there everyone can mimic the proper procedure and at their own features. (I.E. if you have sendMessage people could easiliy copy and change this to kick/teleport/mute etc etc)

    I can do this by Sockets with no problems, I would probably at a method in the ServerObject so I can send a socket to the target ServerObject. (And on the target server I would ofcourse with your TimoCloudBukkit/Bungee instance translate it into what I want it to do)

    That is a very good question. I think it would be very awesome to have this PartyManager instance all over the network. I'm just worried about concurrency and race conditions.

    If that concept is not really appealing my other approach would be :
    - Request the Party data which is stored on the standalone, so we only have 1 instance with this data. I.E. Party party = TimoCloudAPI.getCoreInstance().fetchParty(player.getUniqueId());
    TimoCloudAPI.getCoreinstance().addToParty(PARTYID, player.getUniqueId());
  9. I thought about it, and I think completely synchronous classes are not necessary.
    By now, I think a good communication system could consist of these two things:
    1. Plugins in the Core
    2. A messaging system where you can send a Message object to a recipient, which is e.g. a ServerObject, ProxyObject or CORE. You create a message like

    Message message = new Message();
    message.getData().set(„player_name“, player.getName());

    What about that?
    So you could register to listen for channels and receive the message objects. The best about that could be that we serialize objects automatically with Jackson or stuff like that, so the user can just send custom objects. Or put the properties in the Json object manually.

    Kind regards,
  10. @TimoCrafter
    I agree on you with that, I would highly prefer custom objects on this scenario.
    If this procedure would continue the process of joining a game with a party would be the following.
    1. Player tries to join a game. (Send this JSON request like class JoinGame { UUID uuid;, String group; // Where group is the server group type.}
    2. The Core receives this and checks if the user is in a party
    3. If player is not the leader of the party, send a message back using a JSON request I.E. PlayerMessage { UUID target, String message }
    4. else send a message back using a JSON request I.E. PlayerMessage AND PlayerTeleport {UUID target, String targetServer } (Or even the server object?)

    How would you prefer doing the deseriliazation, since you don't really know what object you get send right?(So what class should you parse it too?) Easy workaround would be to make a 'master class' call it Request and just add every request in there, than you check wether its null or not.
    class Request {
    private PlayerMessage playerMessage;
    private PlayerTeleport playerTeleport;

    If you get what I mean ^

    What would be very cool is to do something like: Party party = TimoCloudAPI.getCoreInstance().getPartyByPlayer(Player player);
    And that would fetch the party object on the CORE side and send it back. (Wouldn't that require callbacks?)

    Best regards,
  11. Hi,
    Regarding deserialization: whenever a user tries to set an object to a key, we don‘t put the object in the map directly, but create an object like {„classpath“: „“, content: „...“}
    And when you want to get the object, we just return object.content.

    You don‘t have to make it that complicated with the player join, as the core will receive the joim event via the event API anyway.

    Kind regards,
  12. @TimoCrafter
    Oh yeah ofcourse, that would be:

    I do not really understand what you mean with the player join.
    I was more planning to create like a clickable player/npc where it auto searches the best game, thats what I mean with the JoinGame part.
    Or what event should I trigger which you are talking about?
  13. Yes, that‘s what I wanted to do with the class.

    You can send whatever events you want, I just wanted to tell you that there is an event API which can notify you when a player joins the network or switches servers and stuff.

    Kind regards,
  14. TimoCrafter updated TimoCloud - The most efficient cloud system with a new update entry:

    [5.1.1] Performance update + bugfixes

    Read the rest of this update entry...
  15. Good pl
    • Agree Agree x 1
    • Friendly Friendly x 1
  16. Ist es normal, dass wenn ich mind. einen Static Server habe und die Cloud starten lasse, dass nur der/die Static Server starten? (auch nach mehreren neustarts, ...)