SP Teams

0.2.0 — Party + Clan foundation · Minecraft Java 26.2 · Fabric · Java 25+

Standalone SP module in xMrShadyx/Minecraft/sp-teams/. Persistent parties and clans, rank permissions, shared treasuries and private chats. Clan progression, skills and raids continue in later milestones from the agreed design.

Clan foundation

Open /clan for Clan, Treasury, Ranks and Find clans tabs.

• Normal creation checks SP RPG level 20, a personal Clan Creation Scroll, and SP Coins. The creation price is deliberately unset until configured through /spadmin → SP Teams → Clan. No final balance price has been chosen. The optional creation quest has not been authored yet.
• New clans are level 1, maximum 10 members. Raising the level and earning clan XP come next. The agreed capacity table up to level 15 is already validated in the data model.
• Online invitations, acceptance/decline, leaving, leader transfer and removal with permission checks. Invitations last 60 seconds and recheck membership, permissions and capacity when accepted. Offline membership persists; the Party system remains independent.
• Fixed Rank 1–9, plus Leader. All non-leader rights start off; new members receive Rank 9. The leader grants separate rights. Delegated rank assignment/removal only manages lower ranks. These neutral rank names/count and delegation hierarchy are initial implementation defaults.
• Every member can deposit SP Coins or either fragment. Withdrawals need separate rights. SP Coins use the existing SP Economy wallet; there is no second personal wallet. Fragment transfers include the existing RPG backpack and restore partial additions on ordinary failures.
• @message goes to online clan members only. # stays Party; ## is reserved for future Raid chat.
• Find clans lists names, leaders, levels and capacity. Introductions, filters and applications come later.

For immediate operator testing: /clan admin create ClanName, then /clan. Admin creation explicitly bypasses the personal creation requirements; normal Create never does. /clan admin scroll grants a bound scroll to the executing operator. /clan admin price <amount> sets a positive creation cost; -1 restores the unconfigured state. Core's admin form offers the same price setting.

Four physical items are registered with original icons in the SP Teams creative tab: sp_teams:skill_ore, sp_teams:clan_skill_fragment, sp_teams:clan_level_fragment, sp_teams:clan_creation_scroll. The first three are tradable; the scroll needs an owner binding. The plain creative-tab scroll is unbound and cannot create a clan. Server quest reward hook: ClanItems.creationScroll(completingPlayer). Bound scrolls cannot be put in external containers or dropped with normal inventory/Q actions; other players cannot pick them up or use them. No item acquisition/drop/recipe source is chosen yet.

Skill/level fragment stocks are available now. Spending them on progression and skills, Skill Ore consumption and all active/passive skill effects are not implemented in 0.2.0. Their separate permission flags are reserved for those later features.

Party foundation

• /party or /spteams: native emerald/gold party window.
• Create a party; invite an online player; accept/decline; leave; leader-only removal and transfer.
• Maximum 9 members, including offline members. Invitations expire after 60 seconds and acceptance rechecks current leadership, membership and capacity. An invitation does not reserve a slot.
• Vertical Party HUD: leader first with crown; current HP, hunger (gold) and armor (blue-grey). Offline members remain in muted rows with an offline label; their current vitals are not fabricated. The HUD remains at its saved position while chat, Esc/pause menus, inventory or the RPG Alt cursor screen is open. The HUD placement editor displays its draft instead of a duplicate panel.
• #message sends only to online party members. @ uses the separate Clan channel. ## is rejected until Raid chat exists, so a private-channel message is not sent to global chat.
• Offline leader window: wait up to five minutes or vote for an online successor. The deadline persists across world/server restarts. A replaced leader remains a party member.
• /spadmin → SP Teams → My party through the existing Core API; no Core changes.
• Server-thread-only read API: dev.xmrshadyx.spteams.api.TeamsApi.party(server, playerUuid).

Player commands: /party create, /party invite <name>, /party accept, /party decline, /party leave, /party wait. Transfer, removal and successor selection are in the party window. The same subcommands work under /spteams.

Initial decisions requiring gameplay feedback

Test invitations without another player

Create a party, then enable cheats/operator permission and run /party test on. Type any valid player name in the party window and click Invite: a simulated member is added immediately with sample HP, food and armor, marked [test]. In this mode invitations never contact real players, even if the entered name belongs to an online player.

/party test off removes all simulated members. They can also be removed individually. Test members are display-only: they are never saved to world data, never returned by TeamsApi, and cannot become leader. Real members stay intact. The normal nine-member limit still applies. The preview clears on server restart, leader disconnect or leadership transfer. The actual two-player invitation/acceptance path remains unchanged outside test mode.

Initial leadership and HUD defaults

The planning confirmed the offline-leader window and five-minute fallback but did not finalize Party voting rules. This prototype uses a strict majority of the other online members for a named successor; Wait casts no successor vote. The earliest still-online member in membership order becomes leader after the deadline. With no online members, membership stays saved and the fallback takes place when an eligible member returns. A returning original leader keeps leadership only if nobody has replaced them. Votes are transient and clear on transfer/reconnect.

A leader voluntarily leaving transfers leadership to the earliest online member, or earliest saved member if all others are offline. The transfer/removal is one persisted operation. These are implementation defaults, not the separate 80% Raid voting rules.

The initial icon is an original geometric shield/group emblem; the final visual design remains open. Open /party → HUD settings to drag the live HUD, adjust X/Y and size (40–150%), then Save. Cancel/Esc discards the draft. The default is a compact 75% panel on the left, away from the usual top-right minimap. Position fits the window as member count/resolution changes. Preferences are local in config/sp-teams/hud.json; no operator permission is needed.

Data and integration boundaries

Membership is world-specific in <world>/sp-teams.json, keyed by player and party UUIDs. Disconnect does not remove a member. Saves use a forced temporary file and replacement before publishing state. Invalid/unsupported data stops Teams loading; the original file is not reset. Back up worlds before testing prerelease mods. Clans use <world>/sp-teams-clans.json; the existing Party format is unchanged. Files belonging to other mods remain separate saves. Ordinary effect/save failures roll back; abrupt crashes are not a cross-file atomic transaction between the clan treasury, economy wallet and Minecraft inventory files.

The API returns immutable current snapshots with party/leader IDs, member names and online status. Consumers must query on the Minecraft server thread and recheck membership before admitting a group. Dungeons stays Solo until an explicit integration updates its membership rules and legacy

Clan progression above level 1, skill learning/effects, castles, wars, applications and Raid systems belong to the next milestones. Their confirmed rules are preserved in docs/DESIGN.md. Prices, quantities and item acquisition are intentionally undecided. Read-only clan integration: ClanApi.clan(server, playerUuid) returns an immutable world-local snapshot.