If enabled, players will need to consume levels to travel from waystone to waystone. The cost can either be fixed, or calculated according to the distance between the used and targeted waystones. The setting can be enabled using the following command:

/function pk_waystones:settings/xp_consumption/set {value:<amount>, mode:<mode>}

This command use two parameters:

• mode waits for either "fixed", "manhattan" or "euclidian". Both last are method used to calculate the distance between waystones.
  • "manhattan" relies on the game's grid, meaning if a waystone is located at 0, 64, 0 and the other at 1000, 64, 1000, the setting will consider both waystone are separated by 2000 blocks.
  • "euclidian" refers to the distance in flight. Meaning if we took this same example above, the process will draw a vector between both waystones and calculate its length. The distance will then be around 1414 blocks.
• value depends on the mode.
  • With the "fixed" mode, it waits for the amount of level the player would consume to teleport from a waystone to any other ones.
  • With "euclidian" or "manhattan" mode, it waits as value the count of blocks you want the player to consume a level for in order to teleport. Meaning for example, if two waystones are separated by 5000 blocks, and I set a value of 1000, it will require 5 levels to teleport to it.
  • In any case, if this value is set to 0 or a negative value, it will disable the setting.

Example - Make teleportation require 5 levels no matter the targeted waystone:

/function pk_waystones:settings/xp_consumption/set {mode:"fixed", value:5}

Example - Consume 1 level for 1000 blocks, with the euclidian calculation method:

/function pk_waystones:settings/xp_consumption/set {mode:"euclidian", value:1000}

Example - Disable the setting completely:

/function pk_waystones:settings/xp_consumption/set {mode:"euclidian", value:0}

If needed, you can also be informed of the current mode and value using the following command:

/function pk_waystones:settings/xp_consumption/get

This setting lets you manage dimensions from the blacklist. The blacklist handles vanilla dimensions, but it also works with custom dimensions from data packs or Multiverse worlds.
In a blacklisted dimension, only managers will be able to place waystones, regular players will not be able to. You can add, remove dimensions to the blacklist or get the list of currently blacklisted dimensions using the following commands respectively:

/function pk_waystones:settings/blacklist_dimensions/add {dimension:<dimension_id>}
/function pk_waystones:settings/blacklist_dimensions/remove {dimension:<dimension_id>}
/function pk_waystones:settings/blacklist_dimensions/list

Example - Disallow waystones placement in the Nether

/function pk_waystones:settings/blacklist_dimensions/add {dimension:"minecraft:the_nether"}

📜 Note: in order to see the dimension id you're currently in, you can open the debug screen (F3), the dimension id is shown below the coordinates on the left side.

If enabled, floating nameplates will appear above waystones, allowing you to identify them more easily. You can enable, disable or get the current state of the setting using these following commands respectively:

/function pk_waystones:settings/display_nameplates/true
/function pk_waystones:settings/display_nameplates/false
/function pk_waystones:settings/display_nameplates/get

Render of nameplates in game:

If enabled, it ignores monsters being around the waystones. If disabled, it prevents players to use a waystone if there are monsters nearby. It is the same principle as the beds use-prevention system. Note that this setting is enabled by default (monsters are ignored). You can enable, disable or get the current state of the setting using these following commands respectively:

/function pk_waystones:settings/ignore_monsters/true
/function pk_waystones:settings/ignore_monsters/false
/function pk_waystones:settings/ignore_monsters/get

If enabled, the data pack will use regular blocks textures for waystones instead of the custom ones. It can be useful if you're using high-resolution resources packs. You can enable, disable or get the current state of the setting using these following commands respectively:

/function pk_waystones:settings/legacy_textures/true
/function pk_waystones:settings/legacy_textures/false
/function pk_waystones:settings/legacy_textures/get

Render of textures in game:

This setting lets you change the default visibility of a waystone on placement. Initially, the default visibility mode is "discoverable". You can set another visibility using the following command, where visibility can be either "discoverable", "private" or "public":

/function pk_waystones:settings/default_visibility/set {visibility:<visibility>}

Example - Set the default waystones visibility on "private"

/function pk_waystones:settings/default_visibility/set {visibility:"private"}

If needed, you can also be informed of the current default visibility using the following command:

/pk_waystones:settings/default_visibility/get

You can chose how many waystones players can own at most. This amount is relative to each player, meaning if you set it to 5, every players will be able to place 5 waystones each. It can be done using the following command, where "count" waits for the desired amount of waystones:

/function pk_waystones:settings/limit_per_player/set {count:<count>}

Example - Allow players to own a maximal amount of 5 waystones each

/function pk_waystones:settings/limit_per_player/set {count:5}

You can also disable this setting using a count of -1 or less, meaning players will be able to place as many waystones as they want:

/function pk_waystones:settings/limit_per_player/set {count:-1}

Or get the current limit using the following command:

/function pk_waystones:settings/limit_per_player/get

Additionnally, you can also limit the amount of waystone your server can contain. This is the exact same principle as above, but instead of being a limit per player, it is a global limit. The commands follow the same scheme to set, disable or get this amount respectively:

/function pk_waystones:settings/limit_per_server/set {count:<count>}
/function pk_waystones:settings/limit_per_server/set -1
/function pk_waystones:settings/limit_per_server/get

You can also combine both settings if you want to set a limit per player but also a global limit on the server.

If enabled, no player will be able to see waystones location from the GUI, unless they have the manager role. You can enable, disable or get the current state of the setting using these following commands respectively:

/function pk_waystones:settings/hide_coordinates/true
/function pk_waystones:settings/hide_coordinates/false
/function pk_waystones:settings/hide_coordinates/get

Note that another command is usable by non-op players and allow them to hide coordinates of waystones for their own character only. Refer to the "Other commands" section below.

This setting allows you to adjust the minimal delay before a waystone can drop itself when broken. It is useful if you use a plugin that provides an area protection system.

For example with WorldGuard, the plugin will store and give back the last item the player tried to place. But if the player try to place a waystone, it will still exist for a single tick and drop itself while being removed by the plugin. In order to avoid that, you can set a lootable delay of 2 ticks.

By default, no delay is checked. You can set a delay (in ticks) with the following command:

/function pk_waystones:settings/lootable_delay/set {delay:<delay>}

Example - Set a delay of 2 ticks:

/function pk_waystones:settings/lootable_delay/set {delay:2}

Or get the current delay using the following command:

/function pk_waystones:settings/lootable_delay/get

External versions such as Paper sometimes involve weird behavior with containers. In order to avoid potential items dupe issues with them, you can tick the system that clear items players may have managed to take from a waystone's GUI using this setting.

You can enable, disable or get the current state of this setting using these following commands respectively:

/function pk_waystones:settings/tick_clear_gui_items/true
/function pk_waystones:settings/tick_clear_gui_items/false
/function pk_waystones:settings/tick_clear_gui_items/get

These permissions allows you to restrict players from using specific visibility values. Note that managers are immune to this effect and will always be able to change any attributes from any waystone. By default, players are allowed to set any visibility to their waystone.

In order to allow, disallow players to set the public visibility on their waystones, or if you want to get the current state of this permission, you can use the following commands respectively:

/function pk_waystones:settings/permissions/change/visibility/public/true
/function pk_waystones:settings/permissions/change/visibility/public/false
/function pk_waystones:settings/permissions/change/visibility/public/get

Same as above but for the private visibility:

/function pk_waystones:settings/permissions/change/visibility/private/true
/function pk_waystones:settings/permissions/change/visibility/private/false
/function pk_waystones:settings/permissions/change/visibility/private/get

Same as above again, but for the discover visibility:

/function pk_waystones:settings/permissions/change/visibility/private/true
/function pk_waystones:settings/permissions/change/visibility/private/false
/function pk_waystones:settings/permissions/change/visibility/private/get

Finally you can also directly toggle or get all visibilily-based permissions at once:

/function pk_waystones:settings/permissions/change/visibility/all/true
/function pk_waystones:settings/permissions/change/visibility/all/false
/function pk_waystones:settings/permissions/change/visibility/all/get

This permission allows you to restrict players from changing the protection attribute of their own waystones. Note that managers are immune to this effect and will always be able to change any attributes from any waystone. By default, players are allowed to change the protection of their waystone.

In order to allow, disallow players to change their waystones protection attribute, or if you want to get the current state of this permission, you can use the following commands respectively:

/function pk_waystones:settings/permissions/change/protection/true
/function pk_waystones:settings/permissions/change/protection/false
/function pk_waystones:settings/permissions/change/protection/get

This permission allows you to restrict players from changing the shared with attribute of their own waystones. Note that managers are immune to this effect and will always be able to change any attributes from any waystone. By default, players are allowed to change the "shared with" list of their waystones.

In order to allow, disallow players to change their waystones shared with attribute, or if you want to get the current state of this permission, you can use the following commands respectively:

/function pk_waystones:settings/permissions/change/shared_with/true
/function pk_waystones:settings/permissions/change/shared_with/false
/function pk_waystones:settings/permissions/change/shared_with/get

If disabled, this permission force players to only see waystones being in the same dimension as themselves from a waystone's GUI. It can be useful if you don't want players to be able to teleport between different Multiverse worlds. This permission is enabled by default, meaning players can teleport in any dimensions.

You can enable, disable or get the current state of the permission using these following commands respectively:

/function pk_waystones:settings/permissions/tp/in_other_dimensions/true
/function pk_waystones:settings/permissions/tp/in_other_dimensions/false
/function pk_waystones:settings/permissions/tp/in_other_dimensions/get

If disabled, this permission prevents players to teleport if they took a damage from a living entity (as source) in the last 15 seconds. It can be useful if you don't want players to escape a fight by using a waystone on PvP servers. This permission is enabled by default, meaning players can teleport at any moment.

You can enable, disable or get the current state of the permission using these following commands respectively:

/function pk_waystones:settings/permissions/tp/in_fight/true
/function pk_waystones:settings/permissions/tp/in_fight/false
/function pk_waystones:settings/permissions/tp/in_fight/get

If you are an operator of your server or if cheats are enabled in your single-player world, you can give yourself a waystone of any variant using these following commands:

/function pk_waystones:cmd/give/waystone/andesite
/function pk_waystones:cmd/give/waystone/sand
/function pk_waystones:cmd/give/waystone/deepslate
/function pk_waystones:cmd/give/waystone/nether
/function pk_waystones:cmd/give/waystone/mossy

This command allows you to directly place a waystone with a specific set of attributes.
Placing a waystone directly can be useful for data packs developers who want for example to implement natural waystones generation within their own structures.

The function waits for a waystone entry containing the waystone's data. All properties can be omitted, as they would simply get their default values if they are missing. But there are two particular contexts you need to know:

• If you don't specify an owner, it will be considered as "unclaimed". Unclaimed waystones will automatically be owned by the first player who uses it.
• Coordinates will be defined from the context of location of the command. However: if you don't specify a location > dimension, the waystone will be registered in the overworld. This is due to the fact we unfortunately can't dynamically detect in what potential custom dimension a command is ran if the executor isn't a player.

This command must always use an already loaded area as context of location. You can forceload the relative chunk upstream and unload it afterwards if you want to set it at a hard location.

Here are several examples of commands:

Set a waystone with all default properties values at the current location:

/function pk_waystones:cmd/setblock/waystone {waystone:{}}

Set a deepslate unclaimed waystone at the current location:

/function pk_waystones:cmd/setblock/waystone {waystone:{variant:"deepslate"}}

Set an unclaimed, protected and public waystone at 0 80 0 in the End:

/execute in minecraft:the_end positioned 0 80 0 run forceload add ~ ~
/execute in minecraft:the_end positioned 0 80 0 run function pk_waystones:cmd/setblock/waystone {waystone:{location:{dimension:"minecraft:the_end"},protected:true,visibility:"public"}}
/execute in minecraft:the_end positioned 0 80 0 run forceload remove ~ ~

And here is the data structure for the waystone parameter:

waystone (entry)
├─ id (int): The id of the Waystone
├─ variant (string): The variant of the Waystone (regular, sand, deepslate, nether...)
├─ name (text component): The name of the Waystone
├─ owner (4 int array): The UUID of the owner
├─ location (entry): Location of the Waystone.
│  └─ dimension (string): dimension id, "minecraft:overworld" by default.
├─ discovered_by (array): list of players having interacted with this Waystone
│  └─ (entry)
│     └─ uuid (4 int array): UUID of a player
├─ shared_with (array): list of players the waystone is shared with
│  └─ (entry)
│     ├─ uuid (4 int array): UUID of a player
│     └─ name (string): If the player isn't in the database yet, store its name instead
├─ protected (boolean): Weather the waystone is protected (true) or not (false)
├─ visibility (string): Can be "public", "private" or "discover"
└─ render_item (entry):
   └─ id (string): id of item to render the Waystone in the Waystones list
   └─ tag (entry) [1.20.4 or less]: optional tags of the item 
   └─ components (entry) [1.20.5 or more]: optional components of the item 

This command can be used to reorganise the waystones in the list by providing a list of ids as parameter:

/function pk_waystones:cmd/database/waystones/reorder {ids:<ids>}

Where <ids> is a list of ids ordered in the new expected order. You're not forced to add all waystones ids in the new list: missing ones will be automatically added at the end of the list, in the order they previously were (so you don't need to include private and discoverable waystones of your players). For example if I currently have waystones with the ids 1-2-3-4-5-6-7-8, and I want to make them appear in the order 4-2-1-3-5-6-7-8, I can use this following command:

/function pk_waystones:cmd/database/waystones/reorder {ids:[4,2,1,3]}

Note that regular players will still see their private waystones first, then discovered waystones, then the public ones. Players with the pk.waystones.manager tag will see all waystones in the order they have been created/reorder.

You can find the ids of waystones by granting yourself the manager role (using /tag @s add pk.waystones.manager) and hovering them in a waystone's GUI. They will be displayed in their tooltip.

This command can be used even by players who aren't operators on the server. It allows you to hide coordinates of waystones from waystones' GUI. It can be useful if you're a video maker who plays on a PvP server, and don't want to leak your waystones' location.
Of course, this setting is player-specific. Meaning by changing it, it will only apply for yourself (not for other players).
Using these following commands, if the value is set on 1, waystones' location will be hidden, if set on 0, waystones' location will show:

/trigger pk.waystones.hide_coordinates set 1
/trigger pk.waystones.hide_coordinates set 0

If ever waystones have been broken accidentally (using a kill @e command for example) you can run the following command to recreate all waystones from the database:

/function pk_waystones:cmd/debug/recreate_all_waystones

The process will automatically remove all remaining entities and blocks of broken waystones before placing fresh ones. All data (id, owner, type, attributes...) will be preserved. It may take some time for it to complete, so be sure to get the message telling the process ended successfully before interacting with or placing a waystone.

On server that use external tools like Paper, Spigot... some desynch can happen, and block may not update their blockstates correctly. If ever you get the message "This waystone is currently used by someone else" when no-body is actually using it, you can unlock the loaded waystones using the following command:

/function pk_waystones:cmd/debug/force_waystones_to_unlock

No, this data pack doesn't strictly require a resources pack. It provides a rather-intuitive GUI by itself, and use players heads to render custom textures.

However, a resources pack providing models for Waystones items and GUI has been made by our graphist-artist contributor, Lordphiphi. You can download it from here: Waystones Resources (for Waystones V.3) - by Lordphiphi.

You need to be connected to the internet the first time you use a new type of waystone. The textures of the player heads that are used to create their looks are indeed loaded and cached on the client-side, from (old or current) players skins that are stored on a Mojang server.

If you accidentally used a content that required to be online the first time you use it, and now see regular players heads instead of the expected texture, you can still go in the ".minecraft/assets/skins/" folder, then sort the sub-folders by date, and delete some recent folders. Once that is done, if your game was already started, you will need to restart it to update the cached content.

⚠️ Exceptional issue on 1.20.2: Players heads can sometimes show default player skins (Steve & co.) rather than its actual texture although the whole cache folder are cleared. This is actually an known issue from the game itself that struggle to load a texture depending on the signature's value. This issue has been fixed on 1.20.3.

Waystones can stay locked if their block container didn't update their blockstate correctly when players closed them. Such issues can happen sometimes, especially on modified versions such as Paper or Spigot. In order to force waystones to unlock, there is a debug command:

/function pk_waystones:cmd/debug/force_waystones_to_unlock