firefox wrote:minetest is not minecraft.
This means nothing, just because something is good for Minecraft does not mean that it is bad for Minetest.
firefox wrote:the minetest world is big enough to fit 3 realms into it.
Very true, but it does not have room for an arbitrary number of worlds, which is possible in Minecraft with mods that allow players to create their own dimensions or pocket dimensions. "Minecraft with mods" is the game that most Minecraft players play, and is the most direct competitor to Minetest since modding is one of our goals. If you are going to compare Minetest to Minecraft, you should compare it to Minecraft Forge rather than vanilla Minecraft.
Minetest has the space for about 512 Minecraft-height worlds. But this would limit each world height very severely (only 256 nodes tall), and I think most Minetest players value being able to dig down thousands of nodes. High world height also allows making ores harder to get by burying them deeper.
Deep worlds and many realms requires having disjoint worlds.
linushsao wrote:1.an API to hide the logout/login menu->directly bring player login into server2
2.sync/reload player's datas in server2
TumeniNodes wrote:I had thought a way to do this might be... creating a script which would pretty much take care of all the steps of exiting to main menu, and then selecting a different world to load, while using a visual placeholder (video?)]
This is a subpar solution, because any mods that have global data will have to keep it consistent across each server. This isn't as simple as only syncing when a player moves servers, because the data for a player might be relevant on every server.
Consider the following example. There is a mailbox mod, allowing each player to have one mailbox and for players to send items between mailboxes. Player A and player B have their mailboxes on separate subworlds, and player A tries to send an item to player B. The code running on A's subworld will need to send the item data to B's subworld, B's subworld will need to modify the world (if the mailbox exists and isn't full), and send back to A's subworld whether the transaction succeeded. Having state spread across different servers will introduce concurrency-related bugs into modding.
It would also make allowing players to have their own subworlds prohibitively expensive, as you will have to spin up a new server for every single subworld. With multiple subworlds in the same server, a new subworld would just be another entry in some std::map (or unordered_map), mostly empty unless the player walks around a lot (which would take up memory on the main world anyway).
Posted: Wed Dec 28, 2016 08:38