Teams API

Non-breaking additions. No changes required for existing providers or consumers.

Added

#### Convenience methods - TeamsService.getTeamIds() - returns all team UUIDs for iteration without loading full team objects. - Team.getOwner() - default method returning the owner's TeamMember record. - VelocityTeam.getMemberUUIDs() - returns UUIDs of all members. - VelocityTeam.getOwner() - default method returning the owner's record. #### Role prefix reset New resetPrefixOverride() method on both TeamRole and TeamRoleDefinition clears any active prefix override, restoring the built-in default:

TeamRole.OWNER.setPrefixOverride("[Lord]");
TeamRole.OWNER.resetPrefixOverride(); // back to "Owner"

Equivalent to calling setPrefixOverride(null). - TeamsAPI.API_VERSION updated to 2.5.0.

Changed

- docs/api.md Team lookup section now correctly lists getTeam, getTeamByName, and getPlayerTeam alongside getAllTeams, getTeamCount, and getTeamIds. - docs/velocity.md updated to document getMemberUUIDs() and getOwner() on VelocityTeam.

Migration

No behavioural changes for existing providers or consumers.

Non-breaking additions. No changes required for existing providers or consumers.

Added

#### Convenience methods - TeamsService.getTeamIds() - returns all team UUIDs for iteration without loading full team objects. - Team.getOwner() - default method returning the owner's TeamMember record. - VelocityTeam.getMemberUUIDs() - returns UUIDs of all members. - VelocityTeam.getOwner() - default method returning the owner's record. #### Role prefix reset New resetPrefixOverride() method on both TeamRole and TeamRoleDefinition clears any active prefix override, restoring the built-in default:

TeamRole.OWNER.setPrefixOverride("[Lord]");
TeamRole.OWNER.resetPrefixOverride(); // back to "Owner"

Equivalent to calling setPrefixOverride(null). - TeamsAPI.API_VERSION updated to 2.5.0.

Changed

- docs/api.md Team lookup section now correctly lists getTeam, getTeamByName, and getPlayerTeam alongside getAllTeams, getTeamCount, and getTeamIds. - docs/velocity.md updated to document getMemberUUIDs() and getOwner() on VelocityTeam.

Migration

No behavioural changes for existing providers or consumers.

Non-breaking additions. No changes required for existing providers or consumers.

Added

#### Role prefix overrides Consumers can now customise the display prefix for any built-in TeamRole constant at runtime:

// Override a single role
TeamRole.OWNER.setPrefixOverride("[Lord]");

// Read back: returns override when set, default otherwise
String prefix = TeamRole.OWNER.getPrefix(); // "[Lord]"

// Original default is always available
String def = TeamRole.OWNER.getDefaultPrefix(); // "Owner"

// Clear the override
TeamRole.OWNER.setPrefixOverride(null);

For bulk operations two static helpers are available:

// Apply multiple overrides at once (null value clears that role's override)
TeamRole.applyPrefixes(Map.of(
    TeamRole.OWNER, "[Lord]",
    TeamRole.ADMIN, "[Officer]"
));

// Clear all overrides for every built-in role
TeamRole.resetAllPrefixes();

New methods on TeamRole: - getDefaultPrefix() - compile-time default prefix, unaffected by any override - setPrefixOverride(String) - sets or clears (null) a JVM-wide prefix override - applyPrefixes(Map<TeamRole, String>) - bulk-sets overrides from a map - resetAllPrefixes() - clears overrides on every built-in role constant getPrefix() now returns the override when set, otherwise the compile-time default. Existing calls to `getPrefix()` require no changes. #### Custom role definitions and registry Providers that model roles beyond the three built-in constants (OWNER, ADMIN, MEMBER) can now publish them through a server-wide registry:

// In your provider plugin's onEnable()
TeamRoleDefinition coOwner = new TeamRoleDefinition("co_owner", 75, "Co-Owner");
TeamsAPI.registerCustomRole(this, coOwner);

// In onDisable()
TeamsAPI.unregisterCustomRole("co_owner");

Consumers can look up or enumerate registered definitions:

// Look up by key
Optional<TeamRoleDefinition> role = TeamsAPI.getCustomRole("co_owner");

// Iterate all custom roles (sorted highest priority first)
for (TeamRoleDefinition def : TeamsAPI.getCustomRoles()) {
    getLogger().info(def.getKey() + " - priority " + def.getPriority());
}

// Test presence
if (TeamsAPI.isCustomRoleRegistered("co_owner")) { ... }

TeamRoleDefinition also supports prefix overrides via setPrefixOverride(String), matching the same pattern as TeamRole. New methods on TeamsAPI: - registerCustomRole(Plugin, TeamRoleDefinition) - publishes a custom role - unregisterCustomRole(String) - removes a custom role by key - getCustomRole(String) - looks up a definition by key, returns Optional - getCustomRoles() - snapshot sorted by descending priority - isCustomRoleRegistered(String) - tests presence by key #### TeamMember.getRoleDefinition() TeamMember now has a default method getRoleDefinition() that returns a TeamRoleDefinition wrapping the member's current built-in role:

TeamMember member = ...;
TeamRoleDefinition def = member.getRoleDefinition();
// def.getKey()      -> "owner" / "admin" / "member"
// def.getPriority() -> 100 / 50 / 10

Providers that register custom roles should override this method to return the precise custom definition for the member. - TeamsAPI.API_VERSION updated to 2.4.0.

Migration

No behavioural changes for existing providers or consumers. getPrefix() still returns the same defaults ("Owner", "Admin", "Member") unless a plugin explicitly calls setPrefixOverride(...). The new getDefaultPrefix() method gives a stable, always-available fallback. The custom role registry starts empty; absence of a registered definition for a role key is a valid state.

Non-breaking additions. No changes required for existing providers or consumers.

Added

#### Role prefix overrides Consumers can now customise the display prefix for any built-in TeamRole constant at runtime:

// Override a single role
TeamRole.OWNER.setPrefixOverride("[Lord]");

// Read back: returns override when set, default otherwise
String prefix = TeamRole.OWNER.getPrefix(); // "[Lord]"

// Original default is always available
String def = TeamRole.OWNER.getDefaultPrefix(); // "Owner"

// Clear the override
TeamRole.OWNER.setPrefixOverride(null);

For bulk operations two static helpers are available:

// Apply multiple overrides at once (null value clears that role's override)
TeamRole.applyPrefixes(Map.of(
    TeamRole.OWNER, "[Lord]",
    TeamRole.ADMIN, "[Officer]"
));

// Clear all overrides for every built-in role
TeamRole.resetAllPrefixes();

New methods on TeamRole: - getDefaultPrefix() - compile-time default prefix, unaffected by any override - setPrefixOverride(String) - sets or clears (null) a JVM-wide prefix override - applyPrefixes(Map<TeamRole, String>) - bulk-sets overrides from a map - resetAllPrefixes() - clears overrides on every built-in role constant getPrefix() now returns the override when set, otherwise the compile-time default. Existing calls to `getPrefix()` require no changes. #### Custom role definitions and registry Providers that model roles beyond the three built-in constants (OWNER, ADMIN, MEMBER) can now publish them through a server-wide registry:

// In your provider plugin's onEnable()
TeamRoleDefinition coOwner = new TeamRoleDefinition("co_owner", 75, "Co-Owner");
TeamsAPI.registerCustomRole(this, coOwner);

// In onDisable()
TeamsAPI.unregisterCustomRole("co_owner");

Consumers can look up or enumerate registered definitions:

// Look up by key
Optional<TeamRoleDefinition> role = TeamsAPI.getCustomRole("co_owner");

// Iterate all custom roles (sorted highest priority first)
for (TeamRoleDefinition def : TeamsAPI.getCustomRoles()) {
    getLogger().info(def.getKey() + " - priority " + def.getPriority());
}

// Test presence
if (TeamsAPI.isCustomRoleRegistered("co_owner")) { ... }

TeamRoleDefinition also supports prefix overrides via setPrefixOverride(String), matching the same pattern as TeamRole. New methods on TeamsAPI: - registerCustomRole(Plugin, TeamRoleDefinition) - publishes a custom role - unregisterCustomRole(String) - removes a custom role by key - getCustomRole(String) - looks up a definition by key, returns Optional - getCustomRoles() - snapshot sorted by descending priority - isCustomRoleRegistered(String) - tests presence by key #### TeamMember.getRoleDefinition() TeamMember now has a default method getRoleDefinition() that returns a TeamRoleDefinition wrapping the member's current built-in role:

TeamMember member = ...;
TeamRoleDefinition def = member.getRoleDefinition();
// def.getKey()      -> "owner" / "admin" / "member"
// def.getPriority() -> 100 / 50 / 10

Providers that register custom roles should override this method to return the precise custom definition for the member. - TeamsAPI.API_VERSION updated to 2.4.0.

Migration

No behavioural changes for existing providers or consumers. getPrefix() still returns the same defaults ("Owner", "Admin", "Member") unless a plugin explicitly calls setPrefixOverride(...). The new getDefaultPrefix() method gives a stable, always-available fallback. The custom role registry starts empty; absence of a registered definition for a role key is a valid state.

Non-breaking additions. No changes required for existing providers or consumers.

Added

#### Role prefix overrides Consumers can now customise the display prefix for any built-in TeamRole constant at runtime:

// Override a single role
TeamRole.OWNER.setPrefixOverride("[Lord]");

// Read back: returns override when set, default otherwise
String prefix = TeamRole.OWNER.getPrefix(); // "[Lord]"

// Original default is always available
String def = TeamRole.OWNER.getDefaultPrefix(); // "Owner"

// Clear the override
TeamRole.OWNER.setPrefixOverride(null);

For bulk operations two static helpers are available:

// Apply multiple overrides at once (null value clears that role's override)
TeamRole.applyPrefixes(Map.of(
    TeamRole.OWNER, "[Lord]",
    TeamRole.ADMIN, "[Officer]"
));

// Clear all overrides for every built-in role
TeamRole.resetAllPrefixes();

New methods on TeamRole: - getDefaultPrefix() - compile-time default prefix, unaffected by any override - setPrefixOverride(String) - sets or clears (null) a JVM-wide prefix override - applyPrefixes(Map<TeamRole, String>) - bulk-sets overrides from a map - resetAllPrefixes() - clears overrides on every built-in role constant getPrefix() now returns the override when set, otherwise the compile-time default. Existing calls to `getPrefix()` require no changes. #### Custom role definitions and registry Providers that model roles beyond the three built-in constants (OWNER, ADMIN, MEMBER) can now publish them through a server-wide registry:

// In your provider plugin's onEnable()
TeamRoleDefinition coOwner = new TeamRoleDefinition("co_owner", 75, "Co-Owner");
TeamsAPI.registerCustomRole(this, coOwner);

// In onDisable()
TeamsAPI.unregisterCustomRole("co_owner");

Consumers can look up or enumerate registered definitions:

// Look up by key
Optional<TeamRoleDefinition> role = TeamsAPI.getCustomRole("co_owner");

// Iterate all custom roles (sorted highest priority first)
for (TeamRoleDefinition def : TeamsAPI.getCustomRoles()) {
    getLogger().info(def.getKey() + " - priority " + def.getPriority());
}

// Test presence
if (TeamsAPI.isCustomRoleRegistered("co_owner")) { ... }

TeamRoleDefinition also supports prefix overrides via setPrefixOverride(String), matching the same pattern as TeamRole. New methods on TeamsAPI: - registerCustomRole(Plugin, TeamRoleDefinition) - publishes a custom role - unregisterCustomRole(String) - removes a custom role by key - getCustomRole(String) - looks up a definition by key, returns Optional - getCustomRoles() - snapshot sorted by descending priority - isCustomRoleRegistered(String) - tests presence by key #### TeamMember.getRoleDefinition() TeamMember now has a default method getRoleDefinition() that returns a TeamRoleDefinition wrapping the member's current built-in role:

TeamMember member = ...;
TeamRoleDefinition def = member.getRoleDefinition();
// def.getKey()      -> "owner" / "admin" / "member"
// def.getPriority() -> 100 / 50 / 10

Providers that register custom roles should override this method to return the precise custom definition for the member. - TeamsAPI.API_VERSION updated to 2.4.0.

Migration

No behavioural changes for existing providers or consumers. getPrefix() still returns the same defaults ("Owner", "Admin", "Member") unless a plugin explicitly calls setPrefixOverride(...). The new getDefaultPrefix() method gives a stable, always-available fallback. The custom role registry starts empty; absence of a registered definition for a role key is a valid state.

Added

- New optional TeamsChestService interface for team chest access: getChestIds(teamId), getContents(...), setContents(...), addItem(...), and removeItem(...). - New TeamsAPI chest facade methods: getChestService(), isChestAvailable(), registerChestProvider(plugin, service), registerChestProvider(plugin, service, priority), and unregisterChestProvider(service). - New API tests: TeamsAPIChestTest for chest provider registration, null-safety, priority registration, and service independence from core TeamsService. - New docs pages: provider-chests (provider implementation/registration guidance) and consumer-chests (consumer usage patterns and fallback guards).

Changed

- TeamsAPI version bumped from 2.2.0 to 2.3.0 (non-breaking minor release). - TeamsAPI.API_VERSION bumped to 2.3.0. - README, API docs, provider/consumer guides, server guide, and public listings updated to include the optional chest capability and 2.3.0 dependency examples.

Added

- New optional TeamsChestService interface for team chest access: getChestIds(teamId), getContents(...), setContents(...), addItem(...), and removeItem(...). - New TeamsAPI chest facade methods: getChestService(), isChestAvailable(), registerChestProvider(plugin, service), registerChestProvider(plugin, service, priority), and unregisterChestProvider(service). - New API tests: TeamsAPIChestTest for chest provider registration, null-safety, priority registration, and service independence from core TeamsService. - New docs pages: provider-chests (provider implementation/registration guidance) and consumer-chests (consumer usage patterns and fallback guards).

Changed

- TeamsAPI version bumped from 2.2.0 to 2.3.0 (non-breaking minor release). - TeamsAPI.API_VERSION bumped to 2.3.0. - README, API docs, provider/consumer guides, server guide, and public listings updated to include the optional chest capability and 2.3.0 dependency examples.

Added

- New optional TeamsChestService interface for team chest access: getChestIds(teamId), getContents(...), setContents(...), addItem(...), and removeItem(...). - New TeamsAPI chest facade methods: getChestService(), isChestAvailable(), registerChestProvider(plugin, service), registerChestProvider(plugin, service, priority), and unregisterChestProvider(service). - New API tests: TeamsAPIChestTest for chest provider registration, null-safety, priority registration, and service independence from core TeamsService. - New docs pages: provider-chests (provider implementation/registration guidance) and consumer-chests (consumer usage patterns and fallback guards).

Changed

- TeamsAPI version bumped from 2.2.0 to 2.3.0 (non-breaking minor release). - TeamsAPI.API_VERSION bumped to 2.3.0. - README, API docs, provider/consumer guides, server guide, and public listings updated to include the optional chest capability and 2.3.0 dependency examples.

TeamsAPI now ships official extensions for three popular team plugins. Drop the extension JAR in your plugins/ folder alongside the team plugin and TeamsAPI will automatically pick it up as a provider. No code changes needed.

New: official provider extensions

TeamsAPI 2.2.0 introduces three ready-to-use provider extensions. Each is bundled inside the main teams-api-plugin JAR and provisioned automatically to plugins/TeamsAPI/extensions/ on first startup. **[BetterTeams](https://www.spigotmc.org/resources/betterteams.17664/) extension** (teams-api-extension-betterteams) - Exposes teams, members, invites, warps, and ally/neutral relations through TeamsAPI. - Invite support: invitePlayer and declineInvite work for offline players; acceptInvite requires the invitee to be online at the time of the call. - Relation support covers ALLY and NEUTRAL; BetterTeams does not model enemies or truces. - MEMBER, ALLY, and NEUTRAL relation constants are supported. [Towny Advanced](https://modrinth.com/plugin/towny) extension (teams-api-extension-towny) - Maps Towny towns to teams, residents to members, and nation relationships (ally/enemy) to TeamsAPI relation constants. - Claim lookup fully supported; claim and unclaim mutations are not exposed (Towny manages its own chunk lifecycle). - MEMBER, ALLY, ENEMY, and NEUTRAL relation constants are supported; TRUCE is normalized to NEUTRAL. [KingdomsX](https://www.spigotmc.org/resources/kingdomsx.77782/) extension (teams-api-extension-kingdomsx) - Maps KingdomsX kingdoms to teams, members to members, and diplomatic relations to TeamsAPI constants. - Claim lookup supported; mutations return false (require a live KingdomPlayer context not available through TeamsAPI). - Power read-only; getPlayerMaxPower and getTeamMaxPower always return 0.0 (KingdomsX does not expose a per-player power ceiling in its public API). - MEMBER, ALLY, TRUCE, ENEMY, and NEUTRAL relation constants are supported; relations are applied symmetrically.

New: extension management commands

| Command | Permission | Description | |---------|-----------|-------------| | /teamsapi install <extension> | teamsapi.install (op) | Copies a bundled extension JAR to plugins/TeamsAPI/extensions/. Valid names: betterteams, towny, kingdomsx. | | /teamsapi load <file>.jar | teamsapi.load (op) | Loads and enables an extension from plugins/TeamsAPI/extensions/ without a server restart. |

Installation quick-start

1. The extension JARs are pre-bundled. TeamsAPI copies them to plugins/TeamsAPI/extensions/ on startup automatically. Nothing to download for first-time setup. 2. Run /teamsapi install betterteams (or towny / kingdomsx) to stage the extension for the next restart, or run `/teamsapi load teams-api-extension-betterteams-2.2.0.jar` to activate it immediately without a restart. 3. Install the matching team plugin if it is not already present, then restart (or reload) the server. Full details and a feature matrix are in the [Provider Catalog](https://ez-plugins.github.io/teams-api/provider-catalog.h…

TeamsAPI now ships official extensions for three popular team plugins. Drop the extension JAR in your plugins/ folder alongside the team plugin and TeamsAPI will automatically pick it up as a provider. No code changes needed.

New: official provider extensions

TeamsAPI 2.2.0 introduces three ready-to-use provider extensions. Each is bundled inside the main teams-api-plugin JAR and provisioned automatically to plugins/TeamsAPI/extensions/ on first startup. **[BetterTeams](https://www.spigotmc.org/resources/betterteams.17664/) extension** (teams-api-extension-betterteams) - Exposes teams, members, invites, warps, and ally/neutral relations through TeamsAPI. - Invite support: invitePlayer and declineInvite work for offline players; acceptInvite requires the invitee to be online at the time of the call. - Relation support covers ALLY and NEUTRAL; BetterTeams does not model enemies or truces. - MEMBER, ALLY, and NEUTRAL relation constants are supported. [Towny Advanced](https://modrinth.com/plugin/towny) extension (teams-api-extension-towny) - Maps Towny towns to teams, residents to members, and nation relationships (ally/enemy) to TeamsAPI relation constants. - Claim lookup fully supported; claim and unclaim mutations are not exposed (Towny manages its own chunk lifecycle). - MEMBER, ALLY, ENEMY, and NEUTRAL relation constants are supported; TRUCE is normalized to NEUTRAL. [KingdomsX](https://www.spigotmc.org/resources/kingdomsx.77782/) extension (teams-api-extension-kingdomsx) - Maps KingdomsX kingdoms to teams, members to members, and diplomatic relations to TeamsAPI constants. - Claim lookup supported; mutations return false (require a live KingdomPlayer context not available through TeamsAPI). - Power read-only; getPlayerMaxPower and getTeamMaxPower always return 0.0 (KingdomsX does not expose a per-player power ceiling in its public API). - MEMBER, ALLY, TRUCE, ENEMY, and NEUTRAL relation constants are supported; relations are applied symmetrically.

New: extension management commands

| Command | Permission | Description | |---------|-----------|-------------| | /teamsapi install <extension> | teamsapi.install (op) | Copies a bundled extension JAR to plugins/TeamsAPI/extensions/. Valid names: betterteams, towny, kingdomsx. | | /teamsapi load <file>.jar | teamsapi.load (op) | Loads and enables an extension from plugins/TeamsAPI/extensions/ without a server restart. |

Installation quick-start

1. The extension JARs are pre-bundled. TeamsAPI copies them to plugins/TeamsAPI/extensions/ on startup automatically. Nothing to download for first-time setup. 2. Run /teamsapi install betterteams (or towny / kingdomsx) to stage the extension for the next restart, or run `/teamsapi load teams-api-extension-betterteams-2.2.0.jar` to activate it immediately without a restart. 3. Install the matching team plugin if it is not already present, then restart (or reload) the server. Full details and a feature matrix are in the [Provider Catalog](https://ez-plugins.github.io/teams-api/provider-catalog.h…

TeamsAPI now ships official extensions for three popular team plugins. Drop the extension JAR in your plugins/ folder alongside the team plugin and TeamsAPI will automatically pick it up as a provider. No code changes needed.

New: official provider extensions

TeamsAPI 2.2.0 introduces three ready-to-use provider extensions. Each is bundled inside the main teams-api-plugin JAR and provisioned automatically to plugins/TeamsAPI/extensions/ on first startup. **[BetterTeams](https://www.spigotmc.org/resources/betterteams.17664/) extension** (teams-api-extension-betterteams) - Exposes teams, members, invites, warps, and ally/neutral relations through TeamsAPI. - Invite support: invitePlayer and declineInvite work for offline players; acceptInvite requires the invitee to be online at the time of the call. - Relation support covers ALLY and NEUTRAL; BetterTeams does not model enemies or truces. - MEMBER, ALLY, and NEUTRAL relation constants are supported. [Towny Advanced](https://modrinth.com/plugin/towny) extension (teams-api-extension-towny) - Maps Towny towns to teams, residents to members, and nation relationships (ally/enemy) to TeamsAPI relation constants. - Claim lookup fully supported; claim and unclaim mutations are not exposed (Towny manages its own chunk lifecycle). - MEMBER, ALLY, ENEMY, and NEUTRAL relation constants are supported; TRUCE is normalized to NEUTRAL. [KingdomsX](https://www.spigotmc.org/resources/kingdomsx.77782/) extension (teams-api-extension-kingdomsx) - Maps KingdomsX kingdoms to teams, members to members, and diplomatic relations to TeamsAPI constants. - Claim lookup supported; mutations return false (require a live KingdomPlayer context not available through TeamsAPI). - Power read-only; getPlayerMaxPower and getTeamMaxPower always return 0.0 (KingdomsX does not expose a per-player power ceiling in its public API). - MEMBER, ALLY, TRUCE, ENEMY, and NEUTRAL relation constants are supported; relations are applied symmetrically.

New: extension management commands

| Command | Permission | Description | |---------|-----------|-------------| | /teamsapi install <extension> | teamsapi.install (op) | Copies a bundled extension JAR to plugins/TeamsAPI/extensions/. Valid names: betterteams, towny, kingdomsx. | | /teamsapi load <file>.jar | teamsapi.load (op) | Loads and enables an extension from plugins/TeamsAPI/extensions/ without a server restart. |

Installation quick-start

1. The extension JARs are pre-bundled. TeamsAPI copies them to plugins/TeamsAPI/extensions/ on startup automatically. Nothing to download for first-time setup. 2. Run /teamsapi install betterteams (or towny / kingdomsx) to stage the extension for the next restart, or run `/teamsapi load teams-api-extension-betterteams-2.2.0.jar` to activate it immediately without a restart. 3. Install the matching team plugin if it is not already present, then restart (or reload) the server. Full details and a feature matrix are in the [Provider Catalog](https://ez-plugins.github.io/teams-api/provider-catalog.h…

Added

- Optional RelationNature enum (FRIENDLY, NEUTRAL, HOSTILE) to the model package. Each TeamRelation constant carries a built-in default nature which may be queried with getDefaultNature(). - Consumer override support: TeamRelation#setNatureOverride(RelationNature) and TeamRelation#getNature() - allows server or provider code to re-categorise a relation at runtime. Passing null to setNatureOverride clears the override and restores the builtin default. Overrides are visible JVM-wide because enum constants are singletons. - Unit tests: TeamRelationTest covering default natures and override behaviour.

Changed

- TeamsAPI.API_VERSION bumped to 2.1.0.

Migration

No behavioural changes to existing TeamRelation helpers: isFriendly() and isHostile() remain unchanged and existing consumers require no changes. Providers that wish to reclassify relations (for example treating TRUCE as NEUTRAL) may call setNatureOverride(...) during initialisation.

Added

- Optional RelationNature enum (FRIENDLY, NEUTRAL, HOSTILE) to the model package. Each TeamRelation constant carries a built-in default nature which may be queried with getDefaultNature(). - Consumer override support: TeamRelation#setNatureOverride(RelationNature) and TeamRelation#getNature() - allows server or provider code to re-categorise a relation at runtime. Passing null to setNatureOverride clears the override and restores the builtin default. Overrides are visible JVM-wide because enum constants are singletons. - Unit tests: TeamRelationTest covering default natures and override behaviour.

Changed

- TeamsAPI.API_VERSION bumped to 2.1.0.

Migration

No behavioural changes to existing TeamRelation helpers: isFriendly() and isHostile() remain unchanged and existing consumers require no changes. Providers that wish to reclassify relations (for example treating TRUCE as NEUTRAL) may call setNatureOverride(...) during initialisation.

Added

- Optional RelationNature enum (FRIENDLY, NEUTRAL, HOSTILE) to the model package. Each TeamRelation constant carries a built-in default nature which may be queried with getDefaultNature(). - Consumer override support: TeamRelation#setNatureOverride(RelationNature) and TeamRelation#getNature() - allows server or provider code to re-categorise a relation at runtime. Passing null to setNatureOverride clears the override and restores the builtin default. Overrides are visible JVM-wide because enum constants are singletons. - Unit tests: TeamRelationTest covering default natures and override behaviour.

Changed

- TeamsAPI.API_VERSION bumped to 2.1.0.

Migration

No behavioural changes to existing TeamRelation helpers: isFriendly() and isHostile() remain unchanged and existing consumers require no changes. Providers that wish to reclassify relations (for example treating TRUCE as NEUTRAL) may call setNatureOverride(...) during initialisation.

Added

- TeamRelation.MEMBER constant (ordinal 4) representing the same-team relationship. Providers should return MEMBER from getRelation(A, A) when both team UUIDs are equal. Consumers comparing two players on potentially the same team will now receive a dedicated constant instead of NEUTRAL. - TeamRelation internal hostilityLevel field. isMoreHostileThan() now uses this field instead of ordinal position, correctly placing MEMBER at hostility level -1 (less hostile than ALLY). Results for the original four constants are unchanged. - isFriendly() now returns true for MEMBER in addition to ALLY and TRUCE. - TeamsAPI.API_VERSION bumped to 2.0.0.

Changed

- `ALLY` default color: §a (green / #55FF55) → §b (aqua / #55FFFF). This aligns with the standard Factions color convention where green represents same-team membership. - `TRUCE` default color: §6 (gold / #FFAA00) → §e (yellow / #FFFF55). Aligns legacy code character with MiniMessage <yellow>.

Migration

The four original ordinals (ALLY=0, TRUCE=1, NEUTRAL=2, ENEMY=3) are unchanged. Code that does not reference MEMBER and does not depend on the specific color values of ALLY or TRUCE requires no changes. Consumers that use ALLY or TRUCE default colors (via getLegacyColorCode(), getDefaultHexColor(), or TeamsRelationService.getRelationColor()) should update their color expectations accordingly. Providers that configure their own colors via getRelationColor() overrides are unaffected.

Added

- TeamRelation.MEMBER constant (ordinal 4) representing the same-team relationship. Providers should return MEMBER from getRelation(A, A) when both team UUIDs are equal. Consumers comparing two players on potentially the same team will now receive a dedicated constant instead of NEUTRAL. - TeamRelation internal hostilityLevel field. isMoreHostileThan() now uses this field instead of ordinal position, correctly placing MEMBER at hostility level -1 (less hostile than ALLY). Results for the original four constants are unchanged. - isFriendly() now returns true for MEMBER in addition to ALLY and TRUCE. - TeamsAPI.API_VERSION bumped to 2.0.0.

Changed

- `ALLY` default color: §a (green / #55FF55) → §b (aqua / #55FFFF). This aligns with the standard Factions color convention where green represents same-team membership. - `TRUCE` default color: §6 (gold / #FFAA00) → §e (yellow / #FFFF55). Aligns legacy code character with MiniMessage <yellow>.

Migration

The four original ordinals (ALLY=0, TRUCE=1, NEUTRAL=2, ENEMY=3) are unchanged. Code that does not reference MEMBER and does not depend on the specific color values of ALLY or TRUCE requires no changes. Consumers that use ALLY or TRUCE default colors (via getLegacyColorCode(), getDefaultHexColor(), or TeamsRelationService.getRelationColor()) should update their color expectations accordingly. Providers that configure their own colors via getRelationColor() overrides are unaffected.

Added

- TeamRelation.MEMBER constant (ordinal 4) representing the same-team relationship. Providers should return MEMBER from getRelation(A, A) when both team UUIDs are equal. Consumers comparing two players on potentially the same team will now receive a dedicated constant instead of NEUTRAL. - TeamRelation internal hostilityLevel field. isMoreHostileThan() now uses this field instead of ordinal position, correctly placing MEMBER at hostility level -1 (less hostile than ALLY). Results for the original four constants are unchanged. - isFriendly() now returns true for MEMBER in addition to ALLY and TRUCE. - TeamsAPI.API_VERSION bumped to 2.0.0.

Changed

- `ALLY` default color: §a (green / #55FF55) → §b (aqua / #55FFFF). This aligns with the standard Factions color convention where green represents same-team membership. - `TRUCE` default color: §6 (gold / #FFAA00) → §e (yellow / #FFFF55). Aligns legacy code character with MiniMessage <yellow>.

Migration

The four original ordinals (ALLY=0, TRUCE=1, NEUTRAL=2, ENEMY=3) are unchanged. Code that does not reference MEMBER and does not depend on the specific color values of ALLY or TRUCE requires no changes. Consumers that use ALLY or TRUCE default colors (via getLegacyColorCode(), getDefaultHexColor(), or TeamsRelationService.getRelationColor()) should update their color expectations accordingly. Providers that configure their own colors via getRelationColor() overrides are unaffected.

Added

- TeamsPowerHistoryService optional extension interface for reading and managing power-history entries through TeamsAPI. - New power-history model types: TeamPowerHistoryEntry and TeamPowerHistoryType (GAIN, LOSS, ADJUSTMENT). - New TeamsAPI power-history facade methods: getPowerHistoryService(), isPowerHistoryAvailable(), registerPowerHistoryProvider(plugin, service), registerPowerHistoryProvider(plugin, service, priority), unregisterPowerHistoryProvider(service). - New tests: TeamsAPIPowerHistoryTest (service registration/availability/null-safety) and TeamPowerHistoryTypeTest (enum contract coverage). - TeamsAPI.API_VERSION bumped to 1.8.0.

Added

- TeamsPowerHistoryService optional extension interface for reading and managing power-history entries through TeamsAPI. - New power-history model types: TeamPowerHistoryEntry and TeamPowerHistoryType (GAIN, LOSS, ADJUSTMENT). - New TeamsAPI power-history facade methods: getPowerHistoryService(), isPowerHistoryAvailable(), registerPowerHistoryProvider(plugin, service), registerPowerHistoryProvider(plugin, service, priority), unregisterPowerHistoryProvider(service). - New tests: TeamsAPIPowerHistoryTest (service registration/availability/null-safety) and TeamPowerHistoryTypeTest (enum contract coverage). - TeamsAPI.API_VERSION bumped to 1.8.0.

Added

- TeamsPowerHistoryService optional extension interface for reading and managing power-history entries through TeamsAPI. - New power-history model types: TeamPowerHistoryEntry and TeamPowerHistoryType (GAIN, LOSS, ADJUSTMENT). - New TeamsAPI power-history facade methods: getPowerHistoryService(), isPowerHistoryAvailable(), registerPowerHistoryProvider(plugin, service), registerPowerHistoryProvider(plugin, service, priority), unregisterPowerHistoryProvider(service). - New tests: TeamsAPIPowerHistoryTest (service registration/availability/null-safety) and TeamPowerHistoryTypeTest (enum contract coverage). - TeamsAPI.API_VERSION bumped to 1.8.0.

Added

- TeamsNotificationService optional extension interface for cross-plugin player notifications with provider-controlled authorization via senderPlugin. - Dual notification type support: enum-based built-ins (TeamNotificationType) and custom string notification types for third-party plugin namespaces. - New TeamsAPI notification facade methods: getNotificationService(), isNotificationAvailable(), registerNotificationProvider(plugin, service), registerNotificationProvider(plugin, service, priority), unregisterNotificationProvider(service). - New TeamNotificationType enum with built-in categories: GENERAL, TEAM_JOIN, TEAM_LEAVE, TEAM_INVITE, TEAM_INVITE_ACCEPT, TEAM_INVITE_DECLINE. - New tests: TeamsAPINotificationTest (service registration/availability/null-safety) and TeamNotificationTypeTest (enum contract coverage). - API reference docs and public listings updated with notification service method tables, enum documentation, and examples for both built-in and custom string types. - ClaimTerritoryType enum (WILDERNESS, TEAM, SAFE_ZONE, WAR_ZONE) to represent classic faction territory classes, including SafeZone and WarZone. - TeamClaim.getTerritoryType() default method. Legacy providers map to TEAM automatically unless they override. - TeamClaim.getOwningTeamId() default method for territory-aware ownership lookups. Returns empty for non-team special territory. - TeamsClaimService default methods for special territory support: claimSafeZone(...), claimWarZone(...), unclaimSpecialZone(...), getTerritoryTypeAt(...), isSafeZone(...), and isWarZone(...). - API docs, developer docs, README, and public listings updated with new claim territory capabilities and examples. - TeamsAPI.API_VERSION bumped to 1.7.0.

Added

- TeamsNotificationService optional extension interface for cross-plugin player notifications with provider-controlled authorization via senderPlugin. - Dual notification type support: enum-based built-ins (TeamNotificationType) and custom string notification types for third-party plugin namespaces. - New TeamsAPI notification facade methods: getNotificationService(), isNotificationAvailable(), registerNotificationProvider(plugin, service), registerNotificationProvider(plugin, service, priority), unregisterNotificationProvider(service). - New TeamNotificationType enum with built-in categories: GENERAL, TEAM_JOIN, TEAM_LEAVE, TEAM_INVITE, TEAM_INVITE_ACCEPT, TEAM_INVITE_DECLINE. - New tests: TeamsAPINotificationTest (service registration/availability/null-safety) and TeamNotificationTypeTest (enum contract coverage). - API reference docs and public listings updated with notification service method tables, enum documentation, and examples for both built-in and custom string types. - ClaimTerritoryType enum (WILDERNESS, TEAM, SAFE_ZONE, WAR_ZONE) to represent classic faction territory classes, including SafeZone and WarZone. - TeamClaim.getTerritoryType() default method. Legacy providers map to TEAM automatically unless they override. - TeamClaim.getOwningTeamId() default method for territory-aware ownership lookups. Returns empty for non-team special territory. - TeamsClaimService default methods for special territory support: claimSafeZone(...), claimWarZone(...), unclaimSpecialZone(...), getTerritoryTypeAt(...), isSafeZone(...), and isWarZone(...). - API docs, developer docs, README, and public listings updated with new claim territory capabilities and examples. - TeamsAPI.API_VERSION bumped to 1.7.0.

Added

- TeamsNotificationService optional extension interface for cross-plugin player notifications with provider-controlled authorization via senderPlugin. - Dual notification type support: enum-based built-ins (TeamNotificationType) and custom string notification types for third-party plugin namespaces. - New TeamsAPI notification facade methods: getNotificationService(), isNotificationAvailable(), registerNotificationProvider(plugin, service), registerNotificationProvider(plugin, service, priority), unregisterNotificationProvider(service). - New TeamNotificationType enum with built-in categories: GENERAL, TEAM_JOIN, TEAM_LEAVE, TEAM_INVITE, TEAM_INVITE_ACCEPT, TEAM_INVITE_DECLINE. - New tests: TeamsAPINotificationTest (service registration/availability/null-safety) and TeamNotificationTypeTest (enum contract coverage). - API reference docs and public listings updated with notification service method tables, enum documentation, and examples for both built-in and custom string types. - ClaimTerritoryType enum (WILDERNESS, TEAM, SAFE_ZONE, WAR_ZONE) to represent classic faction territory classes, including SafeZone and WarZone. - TeamClaim.getTerritoryType() default method. Legacy providers map to TEAM automatically unless they override. - TeamClaim.getOwningTeamId() default method for territory-aware ownership lookups. Returns empty for non-team special territory. - TeamsClaimService default methods for special territory support: claimSafeZone(...), claimWarZone(...), unclaimSpecialZone(...), getTerritoryTypeAt(...), isSafeZone(...), and isWarZone(...). - API docs, developer docs, README, and public listings updated with new claim territory capabilities and examples. - TeamsAPI.API_VERSION bumped to 1.7.0.

Added

- TeamRelation.getDisplayName() — returns a human-friendly relation name ("Ally", "Truce", "Neutral", "Enemy"). - TeamRelation.getLegacyColorCode() — returns the legacy Minecraft color code character ('a' green, '6' gold, '7' gray, 'c' red) for use in chat formatting: "§" + relation.getLegacyColorCode(). - TeamRelation.getDefaultHexColor() — returns a #RRGGBB hex string suitable for Adventure / MiniMessage consumers (#55FF55, #FFAA00, #AAAAAA, #FF5555). - TeamsRelationService.getTeamsInRelation(teamId, relation) — default convenience method that returns all team UUIDs toward which teamId has declared the given relation. Providers may override for a more efficient implementation. - TeamsRelationService.getRelationColor(relation) — default method that returns the display color for a relation as a #RRGGBB hex string. Providers may override to supply server-configured colors; falls back to TeamRelation.getDefaultHexColor(). - TeamsAPI.API_VERSION bumped to 1.6.1.

Added

- TeamRelation.getDisplayName() — returns a human-friendly relation name ("Ally", "Truce", "Neutral", "Enemy"). - TeamRelation.getLegacyColorCode() — returns the legacy Minecraft color code character ('a' green, '6' gold, '7' gray, 'c' red) for use in chat formatting: "§" + relation.getLegacyColorCode(). - TeamRelation.getDefaultHexColor() — returns a #RRGGBB hex string suitable for Adventure / MiniMessage consumers (#55FF55, #FFAA00, #AAAAAA, #FF5555). - TeamsRelationService.getTeamsInRelation(teamId, relation) — default convenience method that returns all team UUIDs toward which teamId has declared the given relation. Providers may override for a more efficient implementation. - TeamsRelationService.getRelationColor(relation) — default method that returns the display color for a relation as a #RRGGBB hex string. Providers may override to supply server-configured colors; falls back to TeamRelation.getDefaultHexColor(). - TeamsAPI.API_VERSION bumped to 1.6.1.

Added

- TeamRelation.getDisplayName() — returns a human-friendly relation name ("Ally", "Truce", "Neutral", "Enemy"). - TeamRelation.getLegacyColorCode() — returns the legacy Minecraft color code character ('a' green, '6' gold, '7' gray, 'c' red) for use in chat formatting: "§" + relation.getLegacyColorCode(). - TeamRelation.getDefaultHexColor() — returns a #RRGGBB hex string suitable for Adventure / MiniMessage consumers (#55FF55, #FFAA00, #AAAAAA, #FF5555). - TeamsRelationService.getTeamsInRelation(teamId, relation) — default convenience method that returns all team UUIDs toward which teamId has declared the given relation. Providers may override for a more efficient implementation. - TeamsRelationService.getRelationColor(relation) — default method that returns the display color for a relation as a #RRGGBB hex string. Providers may override to supply server-configured colors; falls back to TeamRelation.getDefaultHexColor(). - TeamsAPI.API_VERSION bumped to 1.6.1.

Added

- TeamRelation enum (ALLY, TRUCE, NEUTRAL, ENEMY) — models the declared relationship one team holds toward another. Includes isFriendly(), isHostile(), and isMoreHostileThan(other) helpers. - TeamsRelationService interface: optional extension service for inter-team relation management. Methods: setRelation(fromTeamId, toTeamId, relation, initiatorUUID), getRelation(fromTeamId, toTeamId) (defaults to NEUTRAL), getRelations(teamId) (returns all non-neutral relations as an unmodifiable map), clearRelations(teamId) (for use on team disband). Default methods: areAllies(teamAId, teamBId) (mutual ALLY required), areEnemies(teamAId, teamBId) (either side suffices). - TeamRelationChangeEvent (cancellable): fired before a team's declared relation toward another changes. Exposes getTargetTeam(), getInitiatorUUID(), getOldRelation(), getNewRelation(), and setNewRelation() so listeners can override the incoming relation before it is persisted. - TeamsAPI facade methods: getRelationService(), isRelationAvailable(), registerRelationProvider(plugin, service), registerRelationProvider(plugin, service, priority), unregisterRelationProvider(service). - TeamsAPI.API_VERSION bumped to 1.6.0.

Added

- TeamRelation enum (ALLY, TRUCE, NEUTRAL, ENEMY) — models the declared relationship one team holds toward another. Includes isFriendly(), isHostile(), and isMoreHostileThan(other) helpers. - TeamsRelationService interface: optional extension service for inter-team relation management. Methods: setRelation(fromTeamId, toTeamId, relation, initiatorUUID), getRelation(fromTeamId, toTeamId) (defaults to NEUTRAL), getRelations(teamId) (returns all non-neutral relations as an unmodifiable map), clearRelations(teamId) (for use on team disband). Default methods: areAllies(teamAId, teamBId) (mutual ALLY required), areEnemies(teamAId, teamBId) (either side suffices). - TeamRelationChangeEvent (cancellable): fired before a team's declared relation toward another changes. Exposes getTargetTeam(), getInitiatorUUID(), getOldRelation(), getNewRelation(), and setNewRelation() so listeners can override the incoming relation before it is persisted. - TeamsAPI facade methods: getRelationService(), isRelationAvailable(), registerRelationProvider(plugin, service), registerRelationProvider(plugin, service, priority), unregisterRelationProvider(service). - TeamsAPI.API_VERSION bumped to 1.6.0.

Added

- TeamRelation enum (ALLY, TRUCE, NEUTRAL, ENEMY) — models the declared relationship one team holds toward another. Includes isFriendly(), isHostile(), and isMoreHostileThan(other) helpers. - TeamsRelationService interface: optional extension service for inter-team relation management. Methods: setRelation(fromTeamId, toTeamId, relation, initiatorUUID), getRelation(fromTeamId, toTeamId) (defaults to NEUTRAL), getRelations(teamId) (returns all non-neutral relations as an unmodifiable map), clearRelations(teamId) (for use on team disband). Default methods: areAllies(teamAId, teamBId) (mutual ALLY required), areEnemies(teamAId, teamBId) (either side suffices). - TeamRelationChangeEvent (cancellable): fired before a team's declared relation toward another changes. Exposes getTargetTeam(), getInitiatorUUID(), getOldRelation(), getNewRelation(), and setNewRelation() so listeners can override the incoming relation before it is persisted. - TeamsAPI facade methods: getRelationService(), isRelationAvailable(), registerRelationProvider(plugin, service), registerRelationProvider(plugin, service, priority), unregisterRelationProvider(service). - TeamsAPI.API_VERSION bumped to 1.6.0.

Added

- TeamsSubcommand interface: providers can register custom subcommands under /teamsapi <name> via TeamsAPI.registerSubcommand(plugin, subcommand). Each subcommand declares a getName(), getDescription(), optional getPermission(), and execute(CommandSender, String[]). - TeamsAPI.registerSubcommand(plugin, subcommand) — registers via Bukkit ServicesManager. - TeamsAPI.unregisterSubcommand(subcommand) — unregisters; call from onDisable. - TeamsAPI.getSubcommands() — returns all registered subcommands as a snapshot. - /teamsapi status — player-accessible (no admin permission required); shows the active provider, team count, and which optional services (invites, warps, claims, power) are registered. - /teamsapi info now shows all five registered service types (TeamsService, InviteService, WarpService, ClaimService, PowerService) and the registered subcommand count. - teamsapi.use permission (default: true) — basic access to /teamsapi. - teamsapi.status permission (default: true) — access to /teamsapi status. - PowerGainSource enum (PASSIVE, PURCHASE, GAMEPLAY, ADMIN) — identifies the origin of a power gain for use in events and listeners. - PowerLossCause enum (DEATH, DECAY, ADMIN) — identifies the reason for a power loss. - TeamPowerGainEvent (cancellable): fired before a player's power is increased. Listeners can modify the gain amount or cancel the event entirely. - TeamPowerLossEvent (cancellable): fired before a player's power is decreased. Listeners can modify the loss amount or cancel the event entirely. - TeamsPowerService#addPlayerPower(UUID, double) default method: adds power to a player clamped to their maximum; built on getPlayerPower/setPlayerPower. - TeamsClaimService#isOverClaimed(UUID) default method: returns true when a team's claim count exceeds its power-gated maximum (power-negative state). - config.yml in the plugin: opt-in passive-regen (periodic power gain for online players) and power-shop (buy power via /teamsapi power buy <n>). - /teamsapi power status — shows the sender's current and max power. - /teamsapi power buy <amount> — purchases power units with Vault economy (requires Vault and power-shop.enabled: true in config). - teamsapi.power and teamsapi.power.buy permission nodes (default: op). - Passive regen scheduler: when passive-regen.enabled: true, grants configurable power to every online team member on a configurable interval. Fires TeamPowerGainEvent; skips if cancelled. Folia-compatible via GlobalRegionScheduler. - Passive regen and power shop are both Folia-compatible. Folia is detected at runtime; GlobalRegionScheduler is used on Folia and BukkitScheduler on Paper / Spigot.

Changed

- /teamsapi now requires teamsapi.use; senders without it receive a permission error instead of the help message. - /teamsapi status now requires teamsapi.status. - /teamsapi info now requires teamsapi.admin. - /teamsapi help (and the bare /teamsapi) only lists subcommands that the sender has permission to execute.

Added

- TeamsSubcommand interface: providers can register custom subcommands under /teamsapi <name> via TeamsAPI.registerSubcommand(plugin, subcommand). Each subcommand declares a getName(), getDescription(), optional getPermission(), and execute(CommandSender, String[]). - TeamsAPI.registerSubcommand(plugin, subcommand) — registers via Bukkit ServicesManager. - TeamsAPI.unregisterSubcommand(subcommand) — unregisters; call from onDisable. - TeamsAPI.getSubcommands() — returns all registered subcommands as a snapshot. - /teamsapi status — player-accessible (no admin permission required); shows the active provider, team count, and which optional services (invites, warps, claims, power) are registered. - /teamsapi info now shows all five registered service types (TeamsService, InviteService, WarpService, ClaimService, PowerService) and the registered subcommand count. - teamsapi.use permission (default: true) — basic access to /teamsapi. - teamsapi.status permission (default: true) — access to /teamsapi status. - PowerGainSource enum (PASSIVE, PURCHASE, GAMEPLAY, ADMIN) — identifies the origin of a power gain for use in events and listeners. - PowerLossCause enum (DEATH, DECAY, ADMIN) — identifies the reason for a power loss. - TeamPowerGainEvent (cancellable): fired before a player's power is increased. Listeners can modify the gain amount or cancel the event entirely. - TeamPowerLossEvent (cancellable): fired before a player's power is decreased. Listeners can modify the loss amount or cancel the event entirely. - TeamsPowerService#addPlayerPower(UUID, double) default method: adds power to a player clamped to their maximum; built on getPlayerPower/setPlayerPower. - TeamsClaimService#isOverClaimed(UUID) default method: returns true when a team's claim count exceeds its power-gated maximum (power-negative state). - config.yml in the plugin: opt-in passive-regen (periodic power gain for online players) and power-shop (buy power via /teamsapi power buy <n>). - /teamsapi power status — shows the sender's current and max power. - /teamsapi power buy <amount> — purchases power units with Vault economy (requires Vault and power-shop.enabled: true in config). - teamsapi.power and teamsapi.power.buy permission nodes (default: op). - Passive regen scheduler: when passive-regen.enabled: true, grants configurable power to every online team member on a configurable interval. Fires TeamPowerGainEvent; skips if cancelled. Folia-compatible via GlobalRegionScheduler. - Passive regen and power shop are both Folia-compatible. Folia is detected at runtime; GlobalRegionScheduler is used on Folia and BukkitScheduler on Paper / Spigot.

Changed

- /teamsapi now requires teamsapi.use; senders without it receive a permission error instead of the help message. - /teamsapi status now requires teamsapi.status. - /teamsapi info now requires teamsapi.admin. - /teamsapi help (and the bare /teamsapi) only lists subcommands that the sender has permission to execute.

Added

- TeamsSubcommand interface: providers can register custom subcommands under /teamsapi <name> via TeamsAPI.registerSubcommand(plugin, subcommand). Each subcommand declares a getName(), getDescription(), optional getPermission(), and execute(CommandSender, String[]). - TeamsAPI.registerSubcommand(plugin, subcommand) — registers via Bukkit ServicesManager. - TeamsAPI.unregisterSubcommand(subcommand) — unregisters; call from onDisable. - TeamsAPI.getSubcommands() — returns all registered subcommands as a snapshot. - /teamsapi status — player-accessible (no admin permission required); shows the active provider, team count, and which optional services (invites, warps, claims, power) are registered. - /teamsapi info now shows all five registered service types (TeamsService, InviteService, WarpService, ClaimService, PowerService) and the registered subcommand count. - teamsapi.use permission (default: true) — basic access to /teamsapi. - teamsapi.status permission (default: true) — access to /teamsapi status. - PowerGainSource enum (PASSIVE, PURCHASE, GAMEPLAY, ADMIN) — identifies the origin of a power gain for use in events and listeners. - PowerLossCause enum (DEATH, DECAY, ADMIN) — identifies the reason for a power loss. - TeamPowerGainEvent (cancellable): fired before a player's power is increased. Listeners can modify the gain amount or cancel the event entirely. - TeamPowerLossEvent (cancellable): fired before a player's power is decreased. Listeners can modify the loss amount or cancel the event entirely. - TeamsPowerService#addPlayerPower(UUID, double) default method: adds power to a player clamped to their maximum; built on getPlayerPower/setPlayerPower. - TeamsClaimService#isOverClaimed(UUID) default method: returns true when a team's claim count exceeds its power-gated maximum (power-negative state). - config.yml in the plugin: opt-in passive-regen (periodic power gain for online players) and power-shop (buy power via /teamsapi power buy <n>). - /teamsapi power status — shows the sender's current and max power. - /teamsapi power buy <amount> — purchases power units with Vault economy (requires Vault and power-shop.enabled: true in config). - teamsapi.power and teamsapi.power.buy permission nodes (default: op). - Passive regen scheduler: when passive-regen.enabled: true, grants configurable power to every online team member on a configurable interval. Fires TeamPowerGainEvent; skips if cancelled. Folia-compatible via GlobalRegionScheduler. - Passive regen and power shop are both Folia-compatible. Folia is detected at runtime; GlobalRegionScheduler is used on Folia and BukkitScheduler on Paper / Spigot.

Changed

- /teamsapi now requires teamsapi.use; senders without it receive a permission error instead of the help message. - /teamsapi status now requires teamsapi.status. - /teamsapi info now requires teamsapi.admin. - /teamsapi help (and the bare /teamsapi) only lists subcommands that the sender has permission to execute.

Fixed

- Publish workflow was uploading original-teams-api-plugin-*.jar (the pre-shade backup) to Modrinth instead of the shaded fat JAR. Servers loading this artifact received a NoClassDefFoundError for com.skyblockexp.teamsapi.api.TeamsAPI. The JAR-locate step now correctly excludes original-*.jar (prefix) rather than *-original.jar (suffix).

Fixed

- Publish workflow was uploading original-teams-api-plugin-*.jar (the pre-shade backup) to Modrinth instead of the shaded fat JAR. Servers loading this artifact received a NoClassDefFoundError for com.skyblockexp.teamsapi.api.TeamsAPI. The JAR-locate step now correctly excludes original-*.jar (prefix) rather than *-original.jar (suffix).

Fixed

- Publish workflow was uploading original-teams-api-plugin-*.jar (the pre-shade backup) to Modrinth instead of the shaded fat JAR. Servers loading this artifact received a NoClassDefFoundError for com.skyblockexp.teamsapi.api.TeamsAPI. The JAR-locate step now correctly excludes original-*.jar (prefix) rather than *-original.jar (suffix).

Added

- TeamClaim model interface: read-only representation of a claimed chunk (teamId, worldName, chunkX, chunkZ, claimedAt). - TeamsClaimService interface: optional extension service for chunk-claim management. Methods: claimChunk, unclaimChunk, unclaimAll, getClaimAt, getTeamClaims, getClaimCount, isClaimed, isClaimedBy, getTeamMaxClaims (-1 means unlimited). - TeamsPowerService interface: optional extension service for player and team power. Methods: getPlayerPower, getPlayerMaxPower, setPlayerPower, getTeamPower, getTeamMaxPower. - TeamClaimEvent (cancellable): fired before a chunk is claimed. - TeamUnclaimEvent (cancellable): fired before a chunk is unclaimed. - TeamsAPI facade methods: registerClaimProvider, unregisterClaimProvider, getClaimService, isClaimAvailable, registerPowerProvider, unregisterPowerProvider, getPowerService, isPowerAvailable. - TeamsAPI.API_VERSION bumped to 1.4.0. --- [Documentation](https://ez-plugins.github.io/teams-api/) · [Modrinth](https://modrinth.com/plugin/teams-api)

Plugin

- Expanded platform support: Spigot, Purpur, and Folia 1.16+ declared alongside Paper. - plugin.yml api-version: '1.16' and folia-supported: true. - Multi-Release JAR: base classes compiled at Java 17; versioned classes at Java 25. - TeamsAPI.API_VERSION bumped to 1.3.0. - Publish workflow builds all JARs, deploys API artifact to GitHub Packages, creates a GitHub Release, and uploads to Modrinth.

Velocity Bridge

- New teams-api-velocity module: Velocity proxy bridge. Proxy-side plugins can query team data asynchronously via VelocityTeamsAPI, VelocityTeamsService, VelocityTeam, VelocityTeamMember, and VelocityTeamRole. - Redis multi-proxy support: optional Redis Pub/Sub bridge (redis.enabled: true in config.yml). Queries that cannot be fulfilled locally are forwarded to another proxy in the network, enabling cross-proxy team queries across multiple Velocity instances behind a shared Redis server. - config.yml generated on first startup. Configurable: Redis host, port, password, database, key prefix, connection pool sizes, socket timeout, and query timeout. - Query timeout configurable via query.timeout-seconds (default 5 s).

BungeeCord Bridge

- New teams-api-bungeecord module: BungeeCord / Waterfall proxy bridge. Mirrors the Velocity bridge via BungeeTeamsAPI, BungeeTeamsService, BungeeTeam, BungeeTeamMember, and BungeeTeamRole. - Redis multi-proxy support: optional Redis Pub/Sub bridge (redis.enabled: true in config.yml). Queries that cannot be fulfilled locally are forwarded to another proxy in the network, enabling cross-proxy team queries across multiple BungeeCord instances behind a shared Redis server. - config.yml generated on first startup. Configurable: Redis host, port, password, database, key prefix, connection pool sizes, socket timeout, and query timeout. - Query timeout configurable via query.timeout-seconds (default 5 s). --- [Documentation](https://ez-plugins.github.io/teams-api/) · [Modrinth](https://modrinth.com/plugin/teams-api)

JitPack does not set the working directory to the project root for install commands, so ./mvnw failed with 'No such file or directory'. Restore the explicit 'cd $HOME/build &&' prefix from the original. Version: 1.2.1 -> 1.2.2 (patch; build-system fix, no API changes)

jitpack.yml: - Clone MockBukkit from minecraft/v26 (dev/26.1.1 was deleted) - Capture dynamic version via git rev-parse and write to /tmp/mb-version.txt - Pass -Dmockbukkit.version=dev-$(cat /tmp/mb-version.txt) to mvnw so Maven resolves the correct local artifact instead of 0.0.0-unset Version: 1.2.0 -> 1.2.1 (patch; build-system fix, no API changes)

- Added TeamWarp model interface (getTeamId, getName, getLocation, getCreatorUUID, getCreatedAt) - Added TeamsWarpService interface (setWarp, removeWarp, getWarp, getWarps) - Added TeamWarpSetEvent (cancellable, fired before setWarp) - Added TeamWarpDeleteEvent (cancellable, fired before removeWarp) - Added warp provider registration/lookup to TeamsAPI facade (getWarpService, isWarpAvailable, registerWarpProvider, unregisterWarpProvider)

What's new in 1.1.0 - Team Invite API

New: TeamsInviteService interface

An optional, independent service interface for team invitation flows. Providers that support invitations register an implementation separately via TeamsAPI.registerInviteProvider(). Existing TeamsService implementations are not required to support it; the API degrades gracefully when no invite provider is registered. Methods: - invitePlayer(UUID teamId, UUID inviterUUID, UUID inviteeUUID) → boolean - acceptInvite(UUID teamId, UUID playerUUID) → Optional<Team> - declineInvite(UUID teamId, UUID playerUUID) → boolean

New: invite provider management on TeamsAPI

- TeamsAPI.getInviteService() - returns the registered TeamsInviteService, or null - TeamsAPI.isInviteAvailable() - returns true if an invite provider is registered - TeamsAPI.registerInviteProvider(Plugin, TeamsInviteService) - registers at Normal priority - TeamsAPI.registerInviteProvider(Plugin, TeamsInviteService, ServicePriority) - registers at a custom priority - TeamsAPI.unregisterInviteProvider(TeamsInviteService) - unregisters the provider on disable All methods follow the existing null-safety contract (null arguments are silently ignored).

New events

| Event | Cancellable | When fired | |---|---|---| | TeamInviteEvent | Yes | Before an invitation is recorded. Cancel to block it. | | TeamInviteAcceptEvent | No | After the player has joined the team. | | TeamInviteDeclineEvent | No | After the pending invitation has been removed. |

Initial release of TeamsAPI, a universal, provider-agnostic bridge plugin for Paper servers, modelled on [Vault](https://github.com/MilkBowl/VaultAPI). ---

What is TeamsAPI?

TeamsAPI decouples plugins that provide team data (faction, clan, guild plugins) from plugins that consume it (scoreboards, chat formatters, quest systems). Neither side needs to know about the other. When the team plugin changes, every consumer keeps working without a recompile. ---

API highlights

- `TeamsAPI` static facade — getService(), isAvailable(), registerProvider(), unregisterProvider() - `TeamsService` interface — team lifecycle, lookup, membership management, and predicate helpers - `Team` / `TeamMember` — read-only snapshot interfaces; providers own the backing data - `TeamRole` enum — OWNER (100) › ADMIN (50) › MEMBER (10) with outranks() and canManage() - 5 cancellable events — TeamCreateEvent, TeamDeleteEvent, TeamJoinEvent, TeamLeaveEvent, TeamRoleChangeEvent - Graceful fallback — if no provider is registered, isAvailable() returns false and all facade methods return safe empty/false values ---

Requirements

- Paper 26.1+ - Java 25+ ---

Installation

Drop teams-api-plugin-1.0.0.jar into your server's plugins/ folder alongside a compatible team plugin, then restart. ---

For developers

Add the API to your project via [JitPack](https://jitpack.io/#ez-plugins/teams-api): - Maven - com.github.ez-plugins:teams-api:1.0.1 (scope provided) - Gradle - compileOnly 'com.github.ez-plugins:teams-api:1.0.1' See the [Developer Guide](https://ez-plugins.github.io/teams-api/developer-guide.html) for provider and consumer integration walkthroughs, and the [API Reference](https://ez-plugins.github.io/teams-api/api.html) for full method tables.