Pack-author practices

Use dedicated progression advancements

For important gates, create a dedicated advancement that represents exactly the milestone needed for access.

Benefits:

• Stable ID under your pack namespace.
• Clear control over criteria.
• No accidental dependency on a mod changing its advancement path.
• No unwanted advancement rewards during team sharing.
• Easy replacement of complex progression logic.

Example ID:

mypack:progression/unlock_the_end

Avoid reward-bearing shared advancements

When FTB Teams sharing is enabled, prefer advancements without XP, loot, recipes, or functions.

Use portal-only sharing for focused co-op progression

Recommended:

shareOnlyPortalAdvancements = true

This prevents unrelated advancements from spreading across the party.

Test as a non-operator Survival player

Creative, Spectator, and operator bypasses can hide configuration mistakes.

Review logs after every pack update

Advancement IDs and dimension IDs can change when mods or datapacks update.

Keep one destination entry

Combine requirements into one gate rather than adding multiple lines for the same dimension.

Use ANY for alternate progression paths

ANY is useful when players may choose between:

• Combat and exploration.
• Two different bosses.
• A quest route and a crafting route.
• Vanilla progression and a modded equivalent.

Back up before changing progression

Changing a gate or team-sharing scope can affect player access and advancement rewards. Back up the world before deploying major progression changes.