What is MassiveCore?

Introducing MCore!

MassiveCore is a Bukkit plugin that contains components the MassiveCraft developers use for developing other Bukkit plugins:

  • ItemStack and Inventory serialization
  • Commands
  • Plugin Integration
  • Data storage with JSON
  • Disc IO
  • … and much more …

Plugins Using MassiveCore













Release Batches


MassiveCore and the plugins built using it are released in batches. All plugins in a release batch have the same version number.

Make sure to update all the plugins at the same time. You may only have one version of MassiveCore installed on your server at the same time.

The Configuration Files

Configuration the ulumulu1510 way :3

The first config is the file /plugins/MassiveCore/conf.json:

For a normal setup (99% of the cases) you can just leave the config file as is. You can edit this config file while the server is running but in order for the changes to take effect you must restart your server.

  • serverid: is an ID for the server. This is currently not used for anything and can be ignored.
  • dburi: is the database URI or alias for the default mstore database.
  • alias2uri: is a “recursive lookup map” for database URI aliases. For example “default” resolves like “default” → “flatfile” → “flatfile://mstore”. The value “flatfile://mstore” means use flatfile storage placing the data flatfiles in the folder “/mstore” (a sibling folder to the “/plugins” folder).

The second config is the database object massivecore_conf/instance:

For a normal setup (99% of the cases) you can just leave the config file as is. You can edit this file when the server is running. The changes will automatically be loaded into the server after a few seconds.

  • aliasesOuterMassiveCore: are the aliases for the outer /massivecore command.
  • aliasesOuterMassiveCoreUsys: are the aliases for the outer /usys command.
  • aliasesOuterMassiveCoreStore: are the aliases for the outer /mstore command.
  • aliasesOuterMassiveCoreBuffer: are the aliases for the outer /buffer command.
  • usingRecipientChatEvent: Required for {factions_relcolor} to work but can be disabled here.
  • permissionDeniedFormats: allows you to set custom denied messages for a permission node. The lookups in this map is “recursive”. For example “some.derp.permission.node.1” would resolve → “derp” → “Only derp people can %s.\nAsk a moderator to become derp.”.
  • permissionToTpdelay: is the normal delay in seconds before teleportation when a plugin makes use of MassiveCore’s delayed teleportation system.
  • deleteFiles: is a list of files which will be kept deleted.
  • catchingMongoDbErrorsOnSave: Wite concern will be ACKNOWLEDGED for true and ERRORS_IGNORED for false. Setting to false may result in performance gain.
  • catchingMongoDbErrorsOnDelete: Wite concern will be ACKNOWLEDGED for true and ERRORS_IGNORED for false. Setting to false may result in performance gain.
  • variableBook: The variable to replace with book in hand content.
  • usingVariableBook: Set to false to disable this feature.
  • variableBuffer: The variable to replace with buffer content.
  • usingVariableBuffer: Set to false to disable this feature.


Some commands in a console window.

  • /mcore use the mcore command
  • /mcore usys use the usys command
  • /mcore mstore use the mstore command
  • /mcore id see the server id
  • /mcore hearsound,hearsounds <sound(s)> hear a sound
    Example: /mcore hearsound WITHER_SPAWN,0.5,1.4 LEVEL_UP,1.0,1.0
  • /mcore buffer use the buffer command
  • /mcore v,version display plugin version and information

Note that /mcore usys and /mcore mstore and /mcore buffer also are available as top-level-commands /usys and /mstore and /buffer.

  • /mstore stats show mstore statistics
  • /mstore listcolls [db=default] list collections in a database
  • /mstore copydb <from> <to> copy database content
  • /usys m,multiverse manage multiverses
  • /usys m,multiverse l,list [page=1] list multiverses
  • /usys m,multiverse s,show <multiverse> show multiverse
  • /usys m,multiverse n,new <multiverse> create new multiverse
  • /usys m,multiverse d,del <multiverse> delete multiverse
  • /usys u,universe manage universes
  • /usys u,universe n,new <universe> <multiverse> create new universe in multiverse
  • /usys u,universe d,del <universe> <multiverse> delete multiverse
  • /usys u,universe c,clear <universe> <multiverse> clear universe in multiverse
  • /usys w,world <world> <universe> <multiverse> set a worlds universe in a multiverse
  • /usys a,aspect manage aspects
  • /usys a,aspect l,list [page=1] list aspects
  • /usys a,aspect s,show <aspect> show aspect
  • /usys a,aspect u,use <aspect> <multiverse> set multiverse for aspect
  • /buffer p,print print buffer
  • /buffer c,clear clear buffer
  • /buffer s,set <string> set buffer
  • /buffer a,add <string> add to buffer
  • /buffer w,whitespace [time=1] add whitespace to buffer

The universe system (usys)

An image of two universes. There is 3 worlds in the universe to the left and 5 worlds in the universe to the right.

The purpose of usys is to offer awesome “multiworld support“. This is best described by example.

An example

Say you are using the vampire plugin and have 5 worlds on your server. The 2 worlds creativeherp and creativederp are creativemode worlds. The 3 worlds survivalfoo, survivalbar and survivalzoot are survivalmode worlds.

Wouldn’t it be great if players could be vampires in the survival-mode worlds but not in the creative-mode worlds? Players are supposed to roleplay in the survival-mode worlds and vampirism is great fun when roleplaying. However in the creative-mode worlds there’s no roleplaying going on and vampirism is irritating and unwanted.

With usys you could then create two universes in your default multiverse:

  • Universe “survival” contains worlds “survivalfoo”, “survivalbar” and “survivalzoot”.
  • Universe “creative” contains worlds “creativederp” and “creativederp”.

Then you point the aspect “vampire_player” to use the default multiverse (this is acctually the case by default)

The Details

  • Each multiverse contains many universes.
  • Each universe contains many worlds.
  • Each world belongs to exactly one universe. (in each multiverse)
  • Each aspect use a certain multiverse.

There’s an undeletable multiverse called “default”.
There’s an undeletable universe called “default” in each multiverse.

An aspect will use the “default” multiverse if nothing else is specified.
A world will use the “default” universe if nothing else is specified.

Aspects are supplied by plugins. The plugin Vampire does for example have two aspects called “vampire_player” and “vampire_config”:

  1. vampire_player: Everything related to player state
    • Is the player a vampire or not?
    • What was the infection reason?
  2. vampire_config: Config options for balancing
    • What is the splash potion radius for holy water?
    • What items are considered wooden stakes?

Multiverses are templates saying what universes exist and what worlds are in them. You will find yourself reusing multiverses, that is pointing many aspects to use the same multiverse.

Tips and Trix

Do you want to remove a world from a universe?
Just assign it to the default universe.

Chat and Command Variables

MassiveCore ships with a small substitution utility. There are special variables you can use in chat or commands.

  • ***book***: Will be replaced with the content of the book you are holding in your hand.
  • ***buffer***: Will be replaced with the content of your buffer. You can manage your buffer using the /buffer command.

These variables are replaced as early as possible, just when the data reaches the server. They can thus be used as a workaround for the limited length of the MineCraft client chat window.

The data store system (mstore)

Store all the things!

MassiveCore contains a data storage/persistence system. With a default config you find all this “data” as flat-files in the folder “mstore” in you server folder.

An especially nice feature is that the storage system polls for changes in the backend. You can change the “.json”-flatfiles during runtime and the changes will be loaded into the server. It is thus possible to point two servers to the same database although data may get lost every once in a while due to write conflicts.

The store system uses GSON for serialization and can use either flatfile or mongodb backend. You specify what database you want to use in the configuration.

Permissions and plugin.yaml