CoreLib Actions

Prerequisite: with EmakiForge enabled, three forge refresh stages are already appended to the CoreLib action registry; reference them from your configured action pipelines to rebuild a held forge layer, refresh one player's inventory, or refresh forged items for all online players after configuration changes

NOTE

Only the stages registered by EmakiForge are covered below. CoreLib built-in stages are documented in CoreLib Actions. Current stage IDs use only the canonical names below; historical aliases are no longer registered. The old emakiforge_refresh_held is now written forge_refresh_held, and the other two follow the same rule

Stage IDs

Stage ID	Purpose	Target requirement
forge_refresh_held	Refreshes the target player's main-hand forged item	REQUIRED_ENTITY
forge_refresh_player	Refreshes forged items in the target player's inventory	REQUIRED_ENTITY
forge_refresh_all	Refreshes forged items for all online players	NONE

Parameters

These stages read no additional parameters (parameters() is an empty list), and every stage reports the category forge

Examples

actions:
  - 'self | forge_refresh_held'
  - 'self | forge_refresh_player'
  # No target needed, so the source can be omitted
  - 'forge_refresh_all'

Notes

• forge_refresh_held only processes the main-hand item. If the player is not holding an item, the stage is skipped
• forge_refresh_player requires a player target and refreshes that player's inventory through the EmakiForge refresh service
• forge_refresh_all declares NONE as its target requirement, so it can stand alone as a whole pipeline. That makes it suitable for admin pipeline templates or bulk refreshes after configuration changes. It waits for the asynchronous refresh to finish, up to 20 seconds; a timeout, a partial failure, or a configuration generation change during the refresh all end the stage in failure