Shogi is a library mod used by Minecraft mods like Waystones to allow for rule-based contextual configuration of properties and events.
For example, it is used to power Waystones' highly customizable warp requirements, allowing players to specify fine-grained conditional costs depending on various factors surrounding the teleport. Some other mods also provide optional support for Shogi rules to allow for extra configurability for things that go beyond the inbuilt basic configuration options.
This guide is for players and modpack developers who want to customize mods that expose Shogi properties. It is recommended to also consult the mod-specific guides, such as the Warp Rules page in the Waystones documentation.
Shogi can be used by any mod developer to provide easy extensibility for their configuration. For information on how to use Shogi when developing your own mods, see the Developer Guide.
You must install the Shogi mod to configure rules for supported mods. Some mods (like Waystones) already have Shogi marked as required dependency, while others only offer optional Shogi support.
If not already installed, download and install Shogi like you would any other mod.
The location where rules can be defined differs depending on the support mod. Consult the other mod's documentation to find out where rules should be configured.
If not otherwise specified, the default file for configuring rules is shogi.rules.json.
For Waystones and Unbreakables, some rules are embedded within the regular config file (waystones-common.toml), while more advanced ones are located in waystones.rules.json (and their equivalent for Unbreakables).
Shogi rules follow a simple pattern:
condition -> effect
Some conditions and effects take parameters:
is_dimension('minecraft:the_end') -> refuse('You cannot use Waystones in the End.')
Note that effects are evaluated in context of the property they are configured for. For example, when the above rule is configured as part of Waystones' warpRequirements option, is_dimension in this case would refer to the player's dimension, and refuse would determine that a teleport is not allowed.
Multiple parameters are separated by commas, and conditions can be negated with an exclamation mark:
!is_block_state_property('origin', 'player') -> refuse('You cannot break generated Waystones')
Again, rules are context-specific, and this example assumes it's defined as part of an Unbreakables rule. In that case, is_block_state_property refers to the block being broken, and refuse determines that the block will be unbreakable with the given error message.
Conditions can be composed using plus, comma or contextual modifiers
is_biome('minecraft:forest') + can_see_sky -> refuse('You can't break forest blocks that can see the sky')
has_mob_effect('minecraft:poison'), has_mob_effect('minecraft:wither') -> refuse('You can't do this while under the effects of Poison or Wither')
offhand(is_item('minecraft:totem_of_undying')) -> refuse('You can't teleport while holding a Totem of Undying')
For a full list of all inbuilt conditions and effects, check the Available Effects page. Mods like Waystones may also provide additional conditions and effects that can be used; refer to the mod-specific guides for a list of those.