Advancement Portals

Overview
Requirements and installation
How dimension gating works
Configuration location
Creating dimension gates
ALL and ANY modes
Legacy configuration support
Complete configuration reference
FTB Teams advancement sharing
Finding dimension and advancement IDs
Player messages and unlock notifications
Bypasses and permissions
Validation and error handling
Examples
Updating from 3.0.x
Troubleshooting
Frequently asked questions
Technical behavior and limitations
Recommended pack-author practices

Overview

Advancement Portals gates player travel to configured dimensions behind Minecraft advancements.

A gate contains:

A destination dimension.
A matching mode.
One or more advancement requirements.

When a player tries to travel to that destination, Advancement Portals checks the player's completed advancements.

If the gate is complete, travel continues normally.
If the gate is incomplete, travel is canceled and the player is shown what is still required.
If no gate exists for the destination, Advancement Portals does nothing.

The mod can use:

Vanilla advancements.
Modded advancements.
Datapack advancements.
Visible advancements.
Hidden advancements.
Dedicated pack-progression advancements.

Advancement Portals does not create the advancements themselves. It reads advancements already loaded by Minecraft, a mod, or a datapack.

Supported environment

Minecraft 1.20.1
Forge 47.x
Java 17
FTB Teams is optional
Mod ID: advancement_portals

Requirements and installation

Place the Advancement Portals jar in the mods folder for the Forge instance.

For a normal modpack installation, include it in both the client and server mod lists. The gate logic is server-authoritative, but matching client and server mod lists are the safest supported distribution.

FTB Teams is not required. When it is absent:

Dimension gates continue to work.
The FTB Teams config section is safely ignored.
No team progress is shared.

When using FTB Teams advancement sharing, use a compatible Forge 1.20.1 FTB Teams release.

How dimension gating works

Advancement Portals listens for player dimension-travel attempts.

Only destinations listed in dimensionRequirements are gated. The source dimension does not matter.

For example:

dimensionRequirements = [
  "minecraft:the_end | ALL | minecraft:nether/obtain_ancient_debris"
]

This means:

Travel to minecraft:the_end is gated.
A player must have completed minecraft:nether/obtain_ancient_debris.
Travel to the Nether, Overworld, or any unlisted modded dimension is unaffected.
Returning from the End to another unlisted destination is unaffected.

The event applies to server players. Non-player entities are not checked by this gate handler.

The system is based on the destination dimension rather than one specific portal block. Any travel method that fires Forge's normal player dimension-travel event can be evaluated by the gate.

Configuration location

The common/server config is generated at:

config/advancement_portals-common.toml

The complete default structure is:

dimensionRequirements = [
  "minecraft:the_nether | ALL | minecraft:story/enchant_item, minecraft:story/mine_diamond",
  "minecraft:the_end | ALL | minecraft:nether/obtain_ancient_debris"
]

[dimensionGating]
enabled = true
creativePlayersBypassGates = true
spectatorPlayersBypassGates = true
operatorsBypassGates = true
operatorBypassPermissionLevel = 2
warningCooldownSeconds = 2
blockedPortalRetryDelayTicks = 20
showAdvancementDescriptions = true
showDimensionUnlockMessages = true

[ftbTeams]
shareAdvancementsWithTeam = true
shareOnlyPortalAdvancements = false
shareRecipeAdvancements = false
syncTeamAdvancementsOnLogin = true
notifySharedAdvancements = true

Applying config changes

The gate parser detects changes to the dimensionRequirements list when the config value is read again. However, startup validation runs when the server starts.

For the most reliable result after editing the common config:

Stop the server.
Edit the config.
Start the server.
Review the validation messages in the server log.

Creating dimension gates

The recommended syntax is:

dimension | ALL/ANY | advancement, advancement

A TOML entry must be inside quotation marks:

"namespace:dimension_path | ALL | namespace:advancement_path"

One advancement

dimensionRequirements = [
  "minecraft:the_nether | ALL | minecraft:story/mine_diamond"
]

Multiple advancements

dimensionRequirements = [
  "minecraft:the_end | ALL | minecraft:nether/obtain_ancient_debris, minecraft:nether/summon_wither"
]

Multiple dimensions

dimensionRequirements = [
  "minecraft:the_nether | ALL | minecraft:story/mine_diamond",
  "minecraft:the_end | ALL | minecraft:nether/obtain_ancient_debris",
  "twilightforest:twilight_forest | ANY | mypack:quests/twilight_key, mypack:bosses/defeat_lich"
]

Spacing

Spaces around | and commas are recommended for readability, but IDs are trimmed by the parser.

This is readable:

"minecraft:the_end | ALL | minecraft:nether/obtain_ancient_debris"

This can also parse:

"minecraft:the_end|ALL|minecraft:nether/obtain_ancient_debris"

Duplicate advancement IDs

Repeated advancement IDs inside one gate are automatically reduced to one requirement.

Example:

"minecraft:the_end | ALL | minecraft:story/mine_diamond, minecraft:story/mine_diamond"

This behaves as though the advancement were listed once.

Duplicate destination IDs

Only one gate is stored per destination.

If the config contains:

dimensionRequirements = [
  "minecraft:the_end | ALL | minecraft:story/mine_diamond",
  "minecraft:the_end | ALL | minecraft:nether/obtain_ancient_debris"
]

The final valid minecraft:the_end entry replaces the earlier entry. A warning is written to the log.

Combine the requirements into a single entry instead:

dimensionRequirements = [
  "minecraft:the_end | ALL | minecraft:story/mine_diamond, minecraft:nether/obtain_ancient_debris"
]

`ALL` and `ANY` modes

`ALL`

ALL requires every listed advancement.

"minecraft:the_end | ALL | mypack:chapter_two, mypack:defeat_wither"

The player must complete both mypack:chapter_two and mypack:defeat_wither.

A locked-travel message lists the requirements that remain incomplete.

The unlock message appears when the final requirement is completed.

`ANY`

ANY requires at least one listed advancement.

"minecraft:the_end | ANY | minecraft:nether/summon_wither, mypack:quests/end_pass"

The player can unlock the End by either:

Summoning the Wither, or
Completing the custom End Pass advancement.

While the gate remains locked, all configured options are incomplete, so the warning lists each available route.

The unlock message appears when the first qualifying advancement is completed.

What is not currently supported

Version 3.1 uses one flat mode per destination. It does not currently support grouped expressions such as:

(A AND B) OR C

A dedicated advancement can represent more complex logic. Create a datapack advancement whose criteria and requirements match the progression expression, then use that advancement as the portal requirement.

Legacy configuration support

The 3.0.x syntax remains accepted:

"minecraft:the_end=[minecraft:end/kill_dragon]"

Multiple requirements are also supported:

"minecraft:the_end=[minecraft:story/mine_diamond,minecraft:nether/obtain_ancient_debris]"

Legacy entries always behave as ALL.

The brackets are optional to the internal parser, but keeping the original format unchanged is recommended until converting to the new syntax.

Recommended replacement:

"minecraft:the_end | ALL | minecraft:end/kill_dragon"

Complete configuration reference

`dimensionRequirements`

Type: list of strings

Defines every dimension gate.

dimensionRequirements = [
  "minecraft:the_nether | ALL | minecraft:story/mine_diamond"
]

An empty list disables all individual gates even when the master switch remains enabled:

dimensionRequirements = []

`[dimensionGating]`

`enabled`

Type: boolean
Default: true

Master switch for all dimension gating.

enabled = true

When false, players may travel without Advancement Portals evaluating configured gates.

`creativePlayersBypassGates`

Type: boolean
Default: true

Allows Creative-mode players to ignore all gates.

creativePlayersBypassGates = true

Set to false when Creative players should be tested against the same advancement requirements.

`spectatorPlayersBypassGates`

Type: boolean
Default: true

Allows Spectator-mode players to ignore all gates.

spectatorPlayersBypassGates = true

`operatorsBypassGates`

Type: boolean
Default: true

Allows operators with the configured permission level to ignore all gates.

operatorsBypassGates = true

`operatorBypassPermissionLevel`

Type: integer
Default: 2
Allowed range: 1 through 4

Controls the permission level required by operatorsBypassGates.

operatorBypassPermissionLevel = 2

This setting has no effect when operatorsBypassGates = false.

`warningCooldownSeconds`

Type: integer
Default: 2
Allowed range: 0 through 60

Controls how often the full locked-travel message may be sent while a player repeatedly triggers the gate.

warningCooldownSeconds = 2

Set to 0 to allow a warning on every blocked event. This can produce chat spam while a player remains in a portal.

`blockedPortalRetryDelayTicks`

Type: integer
Default: 20
Allowed range: 0 through 200

Applies a short portal cooldown after blocked travel.

Twenty ticks is approximately one second:

blockedPortalRetryDelayTicks = 20

This is separate from warningCooldownSeconds.

The retry delay reduces repeated travel events.
The warning cooldown reduces repeated chat messages.

Set to 0 to disable the added retry delay.

`showAdvancementDescriptions`

Type: boolean
Default: true

Shows the advancement description below its title in the locked-travel message.

showAdvancementDescriptions = true

Set to false for a shorter message.

Advancements without display data use their resource ID instead of a title and description.

`showDimensionUnlockMessages`

Type: boolean
Default: true

Shows a chat and action-bar notification when an earned advancement finishes a gate.

showDimensionUnlockMessages = true

This setting does not affect the actual unlock. It controls only the notification.

`[ftbTeams]`

`shareAdvancementsWithTeam`

Type: boolean
Default: true

Master switch for FTB Teams advancement sharing.

shareAdvancementsWithTeam = true

The option is ignored safely when FTB Teams is not installed.

Dimension gating itself does not require FTB Teams.

`shareOnlyPortalAdvancements`

Type: boolean
Default: false

Controls the scope of newly earned advancement sharing.

shareOnlyPortalAdvancements = false

When false:

Newly earned eligible non-recipe advancements can be shared.
Portal requirements are also synchronized from existing progress.

When true:

Only advancement IDs referenced by dimensionRequirements are shared.
This is the recommended option when team sharing exists specifically to support gated dimensions.

`shareRecipeAdvancements`

Type: boolean
Default: false

Controls sharing for advancements whose path is inside a recipe folder.

shareRecipeAdvancements = false

Recipe advancement paths are detected when the path begins with recipes/ or contains /recipes/.

Recipe advancements can be extremely numerous and are often invisible, so they are disabled by default.

An advancement explicitly used by a dimension gate remains shareable even when this option is false. This prevents a recipe-based gate from breaking team progression.

`syncTeamAdvancementsOnLogin`

Type: boolean
Default: true

Synchronizes stored team advancement progress when a player joins.

syncTeamAdvancementsOnLogin = true

This is what allows an offline teammate to receive progress after returning.

When disabled, newly earned progress can still be shared immediately to online teammates, and gate-scoped synchronization can still occur during a portal attempt.

`notifySharedAdvancements`

Type: boolean
Default: true

Shows a small system message when a player receives an advancement through team sharing.

notifySharedAdvancements = true

Set to false to share silently.

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.

When a player earns an eligible advancement:

Advancement Portals finds the player's current FTB Teams party.
The advancement is recorded for the party member UUIDs.
Online teammates are granted their remaining criteria for that advancement.
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.

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

When a teammate is offline:

The earned advancement is recorded for that teammate's UUID.
The world saves the record.
The teammate logs in later.
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.

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.

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.

Finding dimension and advancement IDs

Resource location format

Minecraft IDs use:

namespace:path

Examples:

minecraft:the_end
minecraft:end/kill_dragon
twilightforest:twilight_forest
mypack:quests/end_access

Use lowercase IDs unless the providing mod or datapack explicitly defines otherwise. Standard resource locations do not allow spaces.

Finding advancement IDs

Useful methods include:

Inspecting the advancement JSON file in a mod jar or datapack.
Using the /advancement command with command suggestions.
Reviewing the providing mod's documentation.
Checking a KubeJS or datapack advancement script.
Searching the server log or generated data.
Temporarily enabling command suggestions as an operator.

A visible advancement's translated title is not its ID.

For example:

Title: Free the End
ID: minecraft:end/kill_dragon

Finding dimension IDs

Useful methods include:

Reviewing the dimension mod's documentation.
Inspecting datapack dimension JSON paths.
Using commands that provide dimension suggestions.
Checking the mod's source or registry dump.
Reviewing teleport or dimension configuration from the providing mod.

A dimension's displayed name is not always its registry ID.

Validate before release

Start a test server and review the Advancement Portals validation summary.

An advancement ID can be syntactically valid but still unknown because:

The mod providing it is missing.
A datapack failed to load.
The ID changed between mod versions.
The path contains a typo.
The advancement is generated only under certain conditions.
The server and client pack contents differ.

Player messages and unlock notifications

Locked destination header

A blocked player receives a header similar to:

Travel locked: The End

Requirement instruction

For ALL:

Complete all of the following advancements:

For ANY:

Complete any one of the following advancements:

Advancement display

When the advancement has display information, the mod uses its readable title and frame color.

When showAdvancementDescriptions = true, the description is shown below the title.

When an advancement has no display information, its resource ID is shown.

When the advancement cannot be found, the player sees:

Unknown advancement: namespace:path

Action-bar reminder

A short action-bar message states that the destination remains locked.

Unlock message

When enabled, completing the gate shows:

Dimension unlocked: The End

The action bar also confirms that the player can now enter.

For a custom dimension, the path is converted into a readable name by replacing slashes, underscores, and hyphens with spaces and capitalizing each word.

Example:

mydimensions:ancient_sky/upper-realm

Displays approximately as:

Ancient Sky Upper Realm

The namespace is not included in the friendly name.

Bypasses and permissions

Bypass checks occur before gate evaluation.

Creative bypass

creativePlayersBypassGates = true

A Creative player passes every gate.

Spectator bypass

spectatorPlayersBypassGates = true

A Spectator player passes every gate.

Operator bypass

operatorsBypassGates = true
operatorBypassPermissionLevel = 2

A player at or above the configured permission level passes every gate.

To test gates as an operator, use one of these approaches:

Temporarily set operatorsBypassGates = false.
Temporarily remove operator status.
Use a separate non-operator test account.

Being in Creative and being an operator are separate bypass conditions.

Validation and error handling

At server startup, Advancement Portals parses the config and validates the resulting gates.

Invalid resource IDs

An invalid dimension or advancement ID is logged and skipped.

Example of an invalid ID:

Minecraft The End

Correct form:

minecraft:the_end

Invalid mode

Only ALL and ANY are valid.

Invalid:

"minecraft:the_end | BOTH | minecraft:end/kill_dragon"

Valid:

"minecraft:the_end | ALL | minecraft:end/kill_dragon"

Mode parsing is case-insensitive, but uppercase is recommended.

Empty requirement list

A gate with no valid advancement IDs is ignored.

Invalid:

"minecraft:the_end | ALL | "

Unknown advancement

A syntactically valid but unloaded advancement is retained as a requirement and remains incomplete.

This is intentional. A typo should not silently open a protected dimension.

Correct the ID or restore the mod/datapack that provides it.

Missing dimension

A gate targeting a dimension that is not currently loaded is reported as a warning.

The gate can still remain in the parsed config. This is useful when a dependency or datapack is temporarily missing, but it should be corrected before release.

Validation summary

The startup log reports:

Number of loaded gates.
Number of unique advancement requirements.
Number of detected issues.

Always review this summary after editing the config or changing modpack versions.

Examples

Unlock the Nether after obtaining diamonds

dimensionRequirements = [
  "minecraft:the_nether | ALL | minecraft:story/mine_diamond"
]

Unlock the Nether after enchanting and obtaining diamonds

dimensionRequirements = [
  "minecraft:the_nether | ALL | minecraft:story/mine_diamond, minecraft:story/enchant_item"
]

Unlock the End after obtaining Ancient Debris

dimensionRequirements = [
  "minecraft:the_end | ALL | minecraft:nether/obtain_ancient_debris"
]

Two valid ways to unlock the End

dimensionRequirements = [
  "minecraft:the_end | ANY | mypack:bosses/defeat_wither, mypack:quests/end_pass"
]

Gate a modded dimension

dimensionRequirements = [
  "twilightforest:twilight_forest | ALL | mypack:quests/complete_overworld_chapter"
]

Replace the IDs with those used by the installed dimension mod and progression datapack.

Gate several progression stages

dimensionRequirements = [
  "minecraft:the_nether | ALL | mypack:chapters/overworld_complete",
  "twilightforest:twilight_forest | ALL | mypack:chapters/nether_complete",
  "minecraft:the_end | ALL | mypack:chapters/twilight_complete"
]

[ftbTeams]
shareAdvancementsWithTeam = true
shareOnlyPortalAdvancements = true
shareRecipeAdvancements = false
syncTeamAdvancementsOnLogin = true
notifySharedAdvancements = true

[ftbTeams]
shareAdvancementsWithTeam = false

Require operators to obey progression

[dimensionGating]
operatorsBypassGates = false

Shorter locked messages

[dimensionGating]
showAdvancementDescriptions = false

Disable unlock announcements

[dimensionGating]
showDimensionUnlockMessages = false

Updating from 3.0.x

Version 3.1 keeps the original dimensionRequirements key and legacy entry syntax.

An existing entry such as:

"minecraft:the_end=[minecraft:end/kill_dragon]"

continues to work as an ALL gate.

Recommended update process

Back up the world and config.
Replace the old mod jar with version 3.1.0.
Start the server.
Allow the expanded config sections to generate.
Stop the server.
Review [dimensionGating] and [ftbTeams].
Decide whether team advancement sharing should be enabled.
Convert legacy entries to the new syntax when convenient.
Restart the server.
Review validation output.
Test each destination with a normal player.
Test both online and offline team sharing.

Existing team progress

Progress earned before installing 3.1 is not automatically present in the new SavedData history.

The mod can discover configured portal advancements from online teammates during login and portal synchronization.

For best upgrade results:

Have established team members join the server.
Allow login synchronization to run.
Attempt the relevant gated portal with another teammate.
Confirm that the gate advancement is shared.
Check logs if it is not.

Troubleshooting

The portal blocks me but does not show a message

Check:

enabled = true.
The player is not seeing a client chat filter issue.
warningCooldownSeconds is not causing a recent warning to be suppressed.
The correct version of the mod is installed.
The server log does not show an exception.
The attempted destination is the dimension you think it is.

Version 3.1 fixes a previous warning-order bug that could cancel travel before displaying the explanation.

The portal does not block an operator

By default:

operatorsBypassGates = true
operatorBypassPermissionLevel = 2

Disable operator bypass while testing:

operatorsBypassGates = false

Also check Creative and Spectator bypass settings.

The portal never unlocks

Check the server log for an unknown advancement.

Confirm:

The advancement ID is correct.
The advancement exists on the server.
The advancement is fully complete, not partially progressed.
The gate uses the intended ALL or ANY mode.
The destination has only one final gate entry.
The providing mod or datapack loaded successfully.

A syntactically valid but missing advancement intentionally remains blocking.

One of my duplicate gates is ignored

The final valid entry for a destination replaces earlier entries.

Combine the requirements into one gate.

An `ANY` gate acts like `ALL`

Confirm the entry has three pipe-separated sections:

"minecraft:the_end | ANY | advancement:a, advancement:b"

Legacy dimension=[...] entries are always ALL.

Confirm:

FTB Teams is installed on the server.
Both players are members of the same FTB Teams party.
shareAdvancementsWithTeam = true.
The advancement passes the portal-only and recipe filters.
The target player does not already have the advancement.
The FTB Teams version matches the expected Forge 1.20.1 API.
The server log says the FTB Teams integration is ready.
Login synchronization is enabled for offline testing.

Check:

shareOnlyPortalAdvancements = true

Set it to false to share other eligible newly earned advancements.

This is the default:

shareRecipeAdvancements = false

Set it to true to share recipe advancements.

A recipe advancement explicitly used as a portal requirement remains shareable even while the option is false.

An offline teammate did not receive an old advancement

Offline storage records progress earned while the sharing system is active.

For progress earned before 3.1, the mod discovers configured portal requirements from online teammates. It does not reconstruct every historical non-portal advancement.

Have a teammate with the portal advancement join, then allow login or portal synchronization to run.

A shared advancement gave extra rewards

That is expected Minecraft behavior. The mod completes the normal advancement criteria.

Use dedicated reward-free progression advancements or restrict sharing to portal advancements.

A player changed teams and brought progress with them

Shared history is stored by player UUID and merged according to current team membership during synchronization.

Strict team-isolated history is not part of version 3.1.

The config looks correct, but a modded portal bypasses the gate

The travel method must fire Forge's normal EntityTravelToDimensionEvent for a server player.

A mod that moves players through a custom mechanism without that event may bypass this handler. Report the travel mod and exact method used so compatibility can be investigated.

The dimension name in the message is imperfect

Vanilla dimensions have special friendly names. Custom dimensions are formatted from the path of their ID.

Version 3.1 does not yet have per-gate custom display names.

Frequently asked questions

Does every dimension need a gate?

No. Only dimensions listed in dimensionRequirements are affected.

Can I gate the Overworld?

A gate can target minecraft:overworld, but test the behavior carefully. Normal login and respawn mechanics are not the same as ordinary portal travel, and blocking every route into a primary dimension may create an unusable progression state.

Can I use hidden advancements?

Yes. Hidden or display-less advancements can be used as requirements. Display-less advancements appear by resource ID in the locked message.

Can I use quest completion?

Yes, when the quest mod or datapack grants an advancement for that quest. Use that advancement ID as the requirement.

Does the mod read partial advancement progress?

No. A requirement counts only when the advancement progress reports complete.

Does `ANY` mean partial criteria from several advancements can combine?

No. At least one configured advancement must be fully complete.

Can I require one of several groups?

Not directly in 3.1. Use a custom datapack advancement to represent the grouped logic.

Does FTB Teams need to be installed?

Only for team advancement sharing. Normal gating works without it.

Does the whole team need to be online?

No. Newly earned eligible progress is stored for offline party members.

Will a teammate receive all criteria?

The mod awards all remaining criteria for the shared advancement until it becomes complete.

Yes. Use that advancement in a gate and enable portal-only sharing:

dimensionRequirements = [
  "yourmod:next_dimension | ALL | minecraft:end/kill_dragon"
]

[ftbTeams]
shareAdvancementsWithTeam = true
shareOnlyPortalAdvancements = true

Not by default. Recipe advancements are filtered unless enabled or explicitly required by a gate.

Are mobs blocked from dimensions?

No. The gate handler checks server players.

Do Creative players bypass by default?

Yes.

Do operators bypass by default?

Yes, at permission level 2 or higher.

Can I turn off the descriptions?

Yes:

showAdvancementDescriptions = false

Can I disable all gates without deleting them?

Yes:

enabled = false

Can I use the old config?

Yes. Existing 3.0.x entries remain supported.

Technical behavior and limitations

Gate cache

Parsed gates are cached. The cache is rebuilt when the raw dimensionRequirements list changes.

One gate per destination

The internal gate map uses the destination ID as its key. The last valid duplicate entry wins.

Unknown advancement behavior

Unknown advancement IDs are kept in a gate's requirement list and evaluated as missing. This is a fail-closed design.

Advancement completion

The mod uses Minecraft's completed advancement progress. It does not treat individual completed criteria as a completed gate unless the advancement itself is done.

Unlock notifications

Unlock notifications listen for the server-side advancement-earned event.

For ALL, the event that completes the final required advancement triggers the message.

For ANY, the message is suppressed when another qualifying advancement already completed the gate earlier.

Warning memory

The mod tracks the last warning tick for connected player UUIDs. The entry is removed when the player logs out.

Portal retry delay

Blocked travel applies the configured portal cooldown to reduce rapid repeated dimension-travel events. It does not grant Fire Resistance or other effects.

Optional FTB Teams integration

The integration uses reflection so FTB Teams is not a hard code dependency.

If the expected API cannot be resolved, an error is logged once and team sharing is skipped while normal gating remains active.

Stored advancement knowledge is saved per player UUID in the Overworld data storage.

It is not permanently keyed to an FTB team ID in version 3.1.

No administrative commands

Version 3.1 does not currently include commands such as:

/advancementportals reload
/advancementportals validate
/advancementportals check

Restarting the server remains the recommended way to ensure validation runs after configuration changes.

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.

Recommended:

shareOnlyPortalAdvancements = true

This prevents unrelated advancements from spreading across the party.

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.

Advancement Portals

On this page