FTB Teams sharing

The problem it solves

Vanilla advancements are normally tracked per player.

In a cooperative boss fight, only one player may satisfy the exact trigger. For example, one teammate may land the final hit on a boss while the rest of the party participated in the fight.

Without sharing:

• One player receives the advancement.
• That player can enter the gated dimension.
• Other teammates may remain locked out.
• The party may need to repeat the milestone solely to satisfy individual advancement tracking.

Advancement Portals can share eligible advancement completion with the other members of the same FTB Teams party.

Immediate online sharing

When a player earns an eligible advancement:

1. Advancement Portals finds the player's current FTB Teams party.
2. The advancement is recorded for the party member UUIDs.
3. Online teammates are granted their remaining criteria for that advancement.
4. A notification is shown when enabled.

Players outside the party do not receive the advancement.

A player without an FTB Teams party is treated as an individual, so no sharing occurs.

Offline sharing

Team advancement knowledge is saved in the world using Minecraft SavedData.

When a teammate is offline:

1. The earned advancement is recorded for that teammate's UUID.
2. The world saves the record.
3. The teammate logs in later.
4. Login synchronization grants eligible stored advancements.

The data file uses the name:

advancement_portals_team_advancements

The physical save format and location are managed by Minecraft's world data storage.

Gate-scoped portal synchronization

Before evaluating a gated destination, the mod performs a small synchronization limited to that gate's advancement IDs.

This has two benefits:

• A player is not incorrectly blocked when the current team already has the required stored progress.
• The portal check does not scan every advancement stored by a large modpack.

Existing worlds

When a world upgrades to 3.1, the persistent team-sharing file does not yet know all advancement progress earned before the update.

To help existing worlds:

• Login synchronization examines the configured portal requirements completed by online teammates.
• Portal synchronization examines the requirements for the destination being attempted.
• Completed portal requirements found on an online teammate are recorded for the current party and can be applied to the player.

This discovery is intentionally focused on portal requirements. The mod does not scan every advancement ever completed by every player.

New team members

During synchronization, stored advancement knowledge from the current party members is merged and recorded for the current member UUIDs.

This means a new party member can inherit eligible progress already recorded by the team.

Team membership changes

Stored sharing history is associated with player UUIDs, while synchronization uses the player's current FTB Teams membership.

As a result, a player may carry previously recorded advancement knowledge when joining another team, and that stored knowledge can become part of the new team's merged progress during synchronization.

Pack authors who require strict team-bound progression should account for this behavior. A future team-identity-based storage mode would be needed to make shared history permanently belong to one specific FTB team rather than its members.

Advancement rewards

The mod grants the remaining normal criteria for the advancement. It does not create a separate fake access flag.

Therefore, normal advancement completion behavior may run for the receiving teammate, including:

• Experience rewards.
• Recipe rewards.
• Loot rewards.
• Functions.
• Parent or child advancement visibility changes.
• Other mods reacting to advancement completion.

This is standard Minecraft advancement behavior.

For controlled progression, consider creating dedicated advancements that:

• Have no experience reward.
• Have no loot reward.
• Have no function reward.
• Exist only as pack progression flags.
• Use hidden display settings when players do not need to see them.

Preventing recursive sharing

Granting an advancement to a teammate can fire another advancement-earned event. Advancement Portals uses an active-grant guard for each player and advancement combination to prevent the same share operation from looping recursively.

Already completed advancements are not granted again.

When sharing is unavailable

Team sharing is skipped when:

• shareAdvancementsWithTeam = false.
• FTB Teams is not installed.
• The player has no party.
• The FTB Teams API cannot be resolved.
• The advancement is filtered by the sharing settings.
• The target player already completed the advancement.

If FTB Teams cannot be integrated, normal dimension gating continues.