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

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 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 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 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.

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 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 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 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.

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 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 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 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.

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.