This guide assumes you already have a working Minecraft server with the Multiverse plugins installed. If you don’t already have that, try: Install a Minecraft server with CraftBukkit and Multiverse on Ubuntu Linux
I’m going to do most of my configuring at the console so I am leaving the ‘/’ off the front of all of the commands. If you do your configuring from inside the game, you’ll have to put a ‘/’ in front of every command.
Design your multiverse
Think about what you want your multiverse to look like. Maybe draw a diagram. Here’s mine:
Also, maybe come up with more creative names for your worlds than I did. For nether and end portals to work without any trouble, you will want to use the Mutiverse NetherPortals convention. This means that if you have a world called “X” you want to name it corresponding nether world “X_nether” and its corresponding end world “X_the_end.” Using this naming convention isn’t strictly necessary, but it makes things simpler.
For each world, consider the following (remember, each nether and end are considered separate worlds):
- Which game mode should players have (survival, creative, adventure)?
- Which game rules should be in effect?
- Where should the player respawn if they die in this world?
- In which worlds should the player share stats and inventory?
- How will players be able to access the world?
My current setup has a lobby world with portals to other worlds. One portal goes to creative world set with overworld, nether, and end. Another portal goes to a survival world set with overworld, nether, and end. A third portal takes players to a world from an old server, mostly for nostalgia’s sake. In my lobby area, I also added a few unused portals because, in the future, I might want to add a skyblock world or an adventure map or something.
Configure Multiverse Core
For a complete listing of the Multiverse Core commands, see Multiverse Core Command Reference.
Create your worlds
When you initially started the server, the default 3 Minecraft worlds were created (an overworld, nether and an end). These are called “world,” “world_nether,” and “world_the_end.” “world” is considered by the server to be the default world, so the server will give you a hard time if you try to delete it. I just kept the three world created by the server and left their names alone as seen in my multiverse layout. Note: You can create aliases for worlds so you will be able to reference them by a different name. For example you can set the alias “Maldovia” for the world called “world” and then refer to “world” as “Maldovia” instead of “world.” You can create the alias like this:
mv modify set alias Maldovia world
The basic command to create a world is:
mv create {NAME} {ENV} -s [SEED]
In this command:
- {NAME} is the world name. This is required.
- {ENV} is the world environment, either “normal”, “nether” or “end”. This is required.
- [SEED] is the world seed. -s [SEED] is optional.
- For other world creation options, see the command reference I linked to above.
For my simple setup, I used the following:
First the lobby, named “lobby” which is a “normal” world (not nether or end) and I don’t care what seed is used.
/mv create lobby normal
Then, for the creative mode worlds (cworld, cworld_nether, and cworld_the_end) I want to use the same seed:
mv create cworld normal -s myseed
mv create cworld_nether nether -s myseed
mv create cworld_the_end end -s myseed
The 8th world (“old_world”) isn’t created here since I’m importing it from an old server I used to have. I’ll get to that later
Import your pre-existing worlds
IMPORTANT NOTE: Before you mess around with an existing world that you don’t want to destroy, make a backup copy just in case something goes wrong.
The first step is to copy the folder for your existing world into the Minecraft directory on your server. The world folder should be in the same directory as your craftbukkit.jar. If you are copying the world from your normal Minecraft game, this will be one of the folders under “saves” in your local Minecraft directory.
One thing to keep in mind here is that regular Minecraft stores the nether and end worlds inside the the overworld directory while CraftBukkit keeps nether and end worlds in their own directory at the same level as the overworld (so nethers and ends are “next to” overworlds in Craftbukkit rather than “inside” overworlds). Standard Minecraft keeps the nether in a folder called DIM-1 and the end in a folder called DIM1. So, if for example you have a local world on your computer called Superworld, inside the Superworld folder there will be folders called DIM1 and DIM-1. If you want to import all 3 worlds to your CraftBukkit server you would do something like this:
- Move the Superworld folder into the minecraft folder on your server.
- Enter the Superworld folder and move DIM1 and DIM-1 up one directory level so they are the same level as Superworld.
- Rename DIM-1 to Superworld_nether.
- Rename DIM1 to Superworld_the_end
In my case, I’m only bringing in an overworld. Once the world folders are in place, tell Multiverse about the worlds The basic command is:
mv import {NAME} {ENV}
{NAME} is the name of the folder containing the world and {ENV} is either normal, nether, or end.
My old world is in a folder called oldworld, so in my case the command would be:
mv import oldworld normal
When I first tried to import my oldworld, CraftBukkit didn’t accept it. I’m not sure exactly why, but the world was started in Minecraft 1.7 and we were using 1.16 at the time. It’s also possible the world files were damaged or messed up or otherwise corrupted. In any case, my solution to this was to open up the world using the current version of the Minecraft client (locally on my computer). Doing this fixed whatever problem CraftBukkit was complaining about and I was able to get the world working on the server.
Set difficulty and game mode per world
To set the game mode, use the mv modify command:
mv modify set gamemode [thegamemode] [theworldname]
- [thegamemode] is either ‘adventure’, ‘creative’, ‘spectator’, or ‘survival’.
- [theworldname] is one of your world names.
So for my worlds it goes like this:
mv modify set gamemode adventure lobby
mv modify set gamemode survival world
mv modify set gamemode survival world_nether
mv modify set gamemode survival world_the_end
mv modify set gamemode creative cworld
mv modify set gamemode creative cworld_nether
mv modify set gamemode creative cworld_the_end
mv modify set gamemode creative oldworld
Setting the difficulty is similar. We use the same command but replace ‘gamemode’ with ‘difficulty.’ Difficulty can be one of ‘peaceful’, ‘easy,’ ‘normal’, or ‘hard’. In my case, like this:
mv modify set difficulty peaceful lobby
mv modify set difficulty hard world
mv modify set difficulty hard world_nether
mv modify set difficulty hard world_the_end
mv modify set difficulty normal cworld
mv modify set difficulty normal cworld_nether
mv modify set difficulty normal cworld_the_end
mv modify set difficulty easy oldworld
Set gamerules (optional)
Set gamerules in each world. You might not need to change any of these. You have to set the gamerules separately for each world.
mv gamerule {RULE} {VALUE} [WORLD]
mv gamerule doFireTick false cworld
You can see a list of the available gamerules with the command
mv gamerule [ANYWORLDNAME]
Set initial spawn worlds and respawn worlds
Decide which world a player should spawn into the first time they join the server. In my case, I want new players to spawn in the lobby world. I can configure that by setting the firstspawwnworld config option.
mv config firstspawnworld lobby
Where should the players respawn if they haven’t slept in a bed (or their bed is gone)? In plain minecraft, players will always just respawn in the overworld, but Multiverse overrides that behavior and causes all players to just respawn in the world in which they died unless you explicitly set the respawn world for each of your worlds.
The basic command is:
mv modify set respawnWorld world_to_respawn_in world_you_die_in
In my case, I want players that die in world, world_nether, and world_the_end to spawn in world. Basically I want to restore the normal Minecraft respawn behavior.
mv modify set respawnWorld world world_nether
mv modify set respawnWorld world world_the_end
I want players that die in cworld, cworld_nether, or cworld_the_end to spawn in cworld.
mv modify set respawnWorld cworld cworld_nether
mv modify set respawnWorld cworld cworld_the_end
Notice that I don’t have to do anything here for world, cworld, lobby, or oldworld since these player that dies in these worlds should respawn in the same world, which is the default multiverse behavior.
Tell Multiverse not to keep all of the spawn chunks in memory (optional)
By default, Minecarft keeps the spawn chunks of a world in memory. Depending on how many worlds you have in your multiverse, this can end up consuming a lot of memory. You can tell the server not to keep the spawn chunks in memory for some (or all) of the worlds to conserve resources. There is a tradeoff for doing this. If the spawn chunks aren’t in memory, there will be a lag spike every time someone goes from one world to another (because the server has to load the data from disk). You’ll have to decide when to make this tradeoff depending on how often you expect players to enter a particular world.
You can tell the server to not keep the spawn chunks in memory like this:
mv modify set keepSpawnInMemory false [world_name]
I did this for all of my worlds except the survival mode set (world, world_nether, and world_the_end) because I expect players to spend most of their time traveling among those worlds and only rarely go to the other worlds.
Configure Multiverse Nether Portals
For a complete listing of the Multiverse Core commands, see Multiverse Nether Portals Command Reference.
Link up your nether and end worlds
If you used the Multiverse Nether Portals plugin convention of naming your world like myworld, myworld_nether, myworld_the_end (like I did), multiverse will link them up for you without you having to do anything. If you have more creative world naming, you can set these with a command:
mvnp link {end|nether} [FROM_WORLD] {TO_WORLD}
So, if your overworld is called “earth”, your nether is called “fieryheck” and your end is called “themoon”, you would link the worlds like this:
mvnp link nether earth fieryheck
mvnp link end earth themoon
Configure Multiverse Inventories
For a complete listing of the Multiverse Core commands, see Multiverse Inventories Command Reference.
Create inventory groups
First, create the inventory groups. The basic command to create a group is:
mvinv creategroup groupname
You need a group for each set of worlds that will share inventories and stats. In my case, I need 4 different groups:
mvinv creategroup lobby
mvinv creategroup worlds
mvinv creategroup cworlds
mvinv creategroup oldworlds
With the current setup I don’t strictly need the “lobby” group and the “oldworlds” group since there is only one world in each group. It suits my sensibilities to have them anyway, and it will be useful if I want to add more worlds to them later.
Add worlds to inventory groups
Now add the worlds to the groups according to your multiverse layout. The basic command is like this:
mvinv addworld {worldname} {groupname}
For me it goes like this:
mvinv addworld world worlds
mvinv addworld world_nether worlds
mvinv addworld world_the_end worlds
mvinv addworld cworld cworlds
mvinv addworld cworld_nether cworlds
mvinv addworld cworld_the_end cworlds
mvinv addworld lobby lobby
mvinv addworld oldworld oldworld
By default the worlds will share inventories, player stats and other player-related things. You can tweak what exactly is shared (for example maybe you only want to share inventory and not stats) using the following commands:
/mvinv addshares {SHARE[,EXTRA]} {GROUP}
/mvinv removeshares {SHARE[,EXTRA]} {GROUP}
The available shares are hit_points, economy, food_level, saturation, exhaustion, xp, total_xp, lvl, inventory_contents, armor_contents, bed_spawn, maximum_air, remaining_air, fall_distance, fire_ticks, potion_effects, last_location, ender_chest, off_hand. By default a group will share everything.
Make sure none of the worlds appear in more than one group (unless you really mean for it to happen). The behavior might be unpredictable in this case. Specifically watch out for any worlds that remain in the default group after you add them to a different group. There might be some opportunities where you can get interesting interactions among the shares by having some worlds in multiple groups with different sets of shares, but I’ll leave that up to you to experiment with.
To see a list of the available groups, do:
mvinv list
To see a list of the worlds and shares in a group, do:
mvinv info mygroup
And to see the groups a world is a member of, do:
mvinv info myworld
Configure Multiverse Portals
For a complete listing of the Multiverse Core commands, see Multiverse Portals Command Reference.
Create portals
You have to be inside the game to create portals, so if you have been doing all of the previous work from the console (like I have), log in to the server now.
Before you have your portals in place you can travel to the different worlds using the Multiverse teleport command:
/mvtp playername worldname
In the mvtp command, the player name is optional. If you leave it out, you’ll teleport yourself.
There is a simple portal tutorial at https://github.com/Multiverse/Multiverse-Core/wiki/Basics-%28Portals%29 to get you started.
The basic idea is that you are going to use the wand to select the corners of the portal. You get the wand with:
/mvp wand
Once you have the portal corners selected, you create the portal with:
/mvp create {NAME} [DESTINATION]
In the above command, {NAME} is the name of the portal and [DESTINATION] is the place you want the portal to bring a player to. [DESTINATION] is optional. You would want to leave it off if, for example, you want to connect the portal to another portal you haven’t created yet. [DESTINATION] can be:
- A world name: the player will be taken to the spawn area of the world. In this case, [DESTINATION] will be w:worldname. The w: tells the command that you mean to connect to a world. You can also add an optional direction to the destination to specify which direction the player should be facing when the appear at the destination. So w:worldname:ne would cause the player to be facing northeast when they arrive at the destination.
- A portal name: the player will be taken to the portal which can be in the same world or a different world. In this case, [DESTINATION] will be p:portalname.
- A position: The player will be teleported to an exact location. In this case, [DESTINATION] is e:worldname:X,Y,Z[:PITCH:YAW]. The pitch and yaw are optional and are both specified in degrees.
- Pitch is how much the player is looking up or down. Looking straight ahead is pitch 0, looking straight up is pitch -90, and looking straight down is pitch 90 (and you can use anything in between).
- Yaw is the direction the player is looking in. Yaw 0 is looking directly south, yaw -90 is looking directly east, yaw 90 is looking directly west and yaw 180 is looking directly north (and you can use anything in between).
- Here: The player will be teleported to the place where the command was executed. So, you could select the portal, move to a different location and then create the portal with destination ‘here’ (or modify the portal destination if it has already been created). The destination ‘here’ will include the pitch and yaw.
There are some other, more advanced choices for the portal destination which you can read about at the Multiverse Destinations Reference.
You can modify the destination of a portal that has already been created using:
/mvp modify destination [DESTINATION] [-p PORTAL]
Use -p PORTAL to specify the name of the portal you want to modify. If you already have the portal selected, you can leave it off. If you’re not sure which portal you have selected it might be safer to add the -p PORTAL just in case.
So, in my simple example, I want to create a portal to each world in the lobby and have them bring players to the spawn in each of the other overworlds. The list of commands will be as follows (with portal selection using the wand between each command):
mvp create lobby_world w:world
mvp create lobby_cworld w:cworld
mvp create lobby_oldworld w:oldworld
The I will go to those worlds and create a portal back to the lobby. So from cworld, my command is like this (after selection with the wand):
mvp create cworld_lobby w:lobby
I named the portals like fromworld_toworld, so the portal that will take a player from ‘lobby’ to ‘world’ is called lobby_world.
Set portal permissions
By default, players wont actually be able to use any of the portals to access the worlds. If you want all players to be able to use all portals you can simply tell Multiverse to not enforce portal access restrictions:
mvp conf enforceportalaccess false
If you want to limit player access to certain portals you have to modify permissions using a permissions plugin (LuckPerms in my case). The simplest way to do this is to create groups, add permissions to the groups and then add players to the groups.
The command to create a group is:
lp creategroup {GROUPNAME}
To add a player to a group:
lp user {PLAYERNAE} group add {GROUPNAME}
To grant a permission to a group, use:
lp group {GROUPNAME} permission set {PERMISSION} true
{PERMISSION} in this command is the string that describes the permission. For access to a portal, the permission string is multiverse.portal.access.{PORTALNAME}
All players start out in the default group. So, for example if you want every player to be able to use the portal to get from the lobby to the survival mode world you can add portal access to the default group:
lp group default permission set multiverse.portal.access.lobby_world
Maybe I want to have a group of creative players and allow the to use the portal to the creative world. The first player I want to add to the group is BobbyBill:
lp creategroup creativeplayers
lp user BobbyBill group add creativeplayers
lp group default permission set multiverse.portal.access.lobby_cworld
For a full list of Multiverse Portals permissions, see Permissions List (Portals)
Permissions aren’t just for portals. Using luckperms, you can fine tune which commands and worlds and other functionality players have access to. You can get a list of available multiverse permissions at hub.com/Multiverse/Multiverse-Core/wiki/Big-List-O-Permissions
CraftBukkit permissions is a whole topic by itself, so I won’t cover it in detail here.
And that’s it. You should have a working Multiverse.