Ban Entry Structure
Every ban entry has a structure consisting of Criterias, Actions and Triggers
Criterias
A ban entry may have multiple criterias that will be matched against when checking a block or item. Every criteria has to match for a ban entry to fit.
Name | Parameters | Description |
ID | String itemID |
Match the item id (e.g. Blocks without a corresponding item can't be matched |
Meta | int meta | Match the item meta or damage. |
Dimension | String dimName |
the world name where the entry should apply. The id is also allowed |
Nbt | String nbtJson |
Matches the item's NBT tag. For blocks it matches to the tile entity's NBT. For blocks without tile entity this criteria will be ignored. |
Player | String name |
The playername of the player for which the the entry should be valid |
Mod | String modid |
The modID the item will be matched against. The modID is the first part of the item's resource location (e.g. |
Not | Criteria crit |
Negates a given criteria (e.g. |
And | Criteria c1, Criteria c2 |
Combines two criterias with a logical AND. This is not very useful in the ban entry itself because the criterias in the ban entry are already linked to each other with AND |
Or | Criteria c1, Criteria c2 |
Combines two criterias with a logical OR |
Actions
A ban entry may have multiple actions that will be executed when an item or block matches its criterias.
Name | Parameters | Description |
Remove | - |
Removes the item or block from the world. By default the player can keep the block or item that is banned (this is useful when an item is only banned in some dimensions). |
Message | String message | Prints a message to the player. |
Log | - | Logs the incident to the console |
Kick | String kickMessage | Kicks the player from the server with the given message |
Ban | String kickMessage, String banMessage | Bans a player from the server |
ServerCommand | String command | Executes a command in a console point of view |
PlayerCommand | String command | Executes a command in a player point of view |
The command of ServerCommand and PlayerCommand has some patterns for the execution environment:
%p | The player name |
%uuid |
The player's UUID with hypens |
%id | The item id |
%meta | The item meta / damage |
%size | The item stack size |
%dim | The dimension id of the incident |
Triggers
There are different incidents where RestrictIO checks whether the item or block is banned. You can specify for every Ban entry in which case it should be checked.
Name | Description | Checked Items | Performance Cost |
BlockBreak | When a block gets broken | The block being broken | low |
BlockPlace | When a block gets placed | The block being placed | low |
InvScan | Periodic (all 30s) scan of all player inventories | All stacks in the player's inventory | low |
ItemDrop | When a player drops an item or when he dies | The item(s) being dropped | low |
ItemPickup | When a player tries to pickup an item | The items will be picked up | high |
ItemInteract | When a player interacts (item rightclick, block left or rightclick) | The (optional) block the player interacts with and/or (optional) the item in hand | very high |
ReciepeRegistration | When the reciepes get registered. The reciepe will be disabled globally! | All standard shape(less) crafting outputs | on startup |
For performance reasons you should use as few triggers as possible for your needs.
Don't use BlockBreak/BlockPlace in conjunction with ItemInteract!
ItemInteract covers the them.
Examples:
- Blocking a machine that is not placed
- BlockPlace
- ReciepeRegistration (when not allowed anywhere)
- Blocking a machine that may have already been placed
- ItemInteract
- ReciepeRegistration (when not allowed anywhere).
- Completely blocking an item or block that is already in inventories and in the world
- ItemDrop
- ItemPickup
- ItemInteract
- ReciepeRegistration
- InvScan