Party Plugin Compatibility

Mythic Dungeons ships with its own party system, and can also hand party handling over to another plugin. Which one is used is decided by a single option in plugins/MythicDungeons/config.yml:

General:
  # What plugin to use for the party system. Defaults to DungeonParties, which is provided by Mythic Dungeons.
  PartyPlugin: Default

Write the value with exactly the casing shown in the table below. Most of the plugin compares this name without regard to case, but not all of it does: the value is handed to the server unchanged when the plugin itself is looked up, and the developer-facing party API only accepts Default and DungeonParties spelled exactly like that. If the value names a plugin that is not installed, Mythic Dungeons logs ERROR :: Party plugin is set to '<name>', but no such plugin was found! and party support stays off for the whole server.

The option is only read while the plugin is starting, so a change needs a full server restart.

Supported Values

Any other value is treated as a custom party provider: Mythic Dungeons checks that a plugin with that name is installed, then waits for that plugin to register its parties through the IDungeonParty API. It will not create parties on its own.

The Built-in System

With Default (or DungeonParties), Mythic Dungeons runs everything itself and registers two extra commands, /party (aliased /dparty) and /p for party chat. Those two commands are only registered under this setting.

This is also the only setting under which the developer-facing party API (createParty, inviteToParty, disbandParty, getParty, and friends) does anything. With any other provider those calls are refused and log Cannot process API call. Party system is not enabled or the internal party system is not selected. That check is case-sensitive, so PartyPlugin: default in lower case still starts the built-in system and its commands, but every one of those API methods is refused.

What Each Provider Can Do

Mythic Dungeons only mutates a third-party party where that plugin's API supports it.

With paf and MythicRPG, parties are read-only: players must form the party with that plugin's own commands before running /md play. /recruit will still create a listing and the listing will still fill up, but joining it does not put the joining player into the underlying party, so they are dropped again on the next party check and are not taken into the dungeon.

Options That Affect Parties

In config.yml (see Plugin Config for the full list):

• General.PartyChat - enables the built-in party chat. Default false. The /p command it uses is only registered when the built-in system is selected.
• General.LeaderOnlyQueue - only the party leader may start a dungeon for the party. Default true.
• General.ReadyCheckOnCommand, General.ReadyCheckInQueue, General.ReadyCheckTime, General.StartWithoutUnreadyPlayers, General.ReadyCheckRequireLeader - the ready check that runs before a party is sent in.
• General.PartyFinder.ListingBroadcastPeriod - how many minutes there are between broadcasts of a /recruit listing. Default 5.

In a dungeon's own config.yml (see Dungeon Config):

• IgnoreParties - when true, only the player who ran the command enters, even if they are in a party. Default false.
• LeaderOnlyQueue - per-dungeon override of the global option.
• Requirements.MinPartySize (default 1) and Requirements.MaxPartySize (default 4). A party outside that range is told so and does not enter.
• Requirements.MaxPartyDistance - members further than this many blocks from the party leader are left behind. 0 (the default) disables the check. Members in a different world always count as too far. The distance is measured from where the leader was standing when the dungeon was started, or from the player who started it if the leader is not online.
• Requirements.KickDistantMembers - whether a member left behind by MaxPartyDistance is also removed from the party. Default true.

Writing your own party plugin? See Adding Party Support.