ER:LC Actions ER:LC Actions let workflows control or interact with your live ER:LC server.
This page explains each ER:LC action block in detail, including what it does, what it accepts, and what it outputs.
Blocks ER:LC action blocks run through your connected ER:LC server. The server needs at least one player online before ER:LC actions and ER:LC data blocks can execute.
Most ER:LC actions also need a live player to target. If the selected player is not in the server when the workflow runs, actions such as kick, jail, heal, teleport, or private message cannot affect them.
Player Moderation
Messages & Commands
Player State
Server Control
Permissions
Counts
Player Moderation These blocks perform direct moderation actions on ER:LC players. Refresh Player Refreshes a player in-game. Input
Player : The player who should be refreshed. Output
No direct output. The workflow continues after the player is refreshed.
Use it when
A workflow needs to reload a player’s character without removing them from the server.
A staff action should reset a player after another action runs.
Kick Player Kicks a player from the ER:LC server. Input
Player : The player who should be kicked. Output
No direct output. The workflow continues after the player is kicked.
Use it when
A workflow needs to remove a player from the current session.
A staff command or automation confirms that a kick should be applied.
Ban Player Permanently bans a player from the ER:LC server. Input
Player : The player who should be banned. Output
No direct output. The workflow continues after the player is banned.
Use it when
A workflow needs to permanently block a player from rejoining the ER:LC server.
A serious moderation action should also apply an in-game ban.
Unban Player Unbans a player from the ER:LC server. Input
Player : The player who should be unbanned. Output
No direct output. The workflow continues after the player is unbanned.
Use it when
A workflow needs to reverse or expire an in-game ban.
A moderation appeal or manual staff action restores access.
Kill Player Kills a player in-game. Input
Player : The player who should be killed. Output
No direct output. The workflow continues after the action runs.
Use it when
A workflow needs to punish, reset, or stop a player during an active session.
Jail Player Jails a player in-game. Input
Player : The player who should be jailed. Output
No direct output. The workflow continues after the player is jailed.
Use it when
A workflow needs to place a player in jail after a staff command, condition, or moderation event.
Respawn Player Respawns a player in-game. Input
Player : The player who should be respawned. Output
No direct output. The workflow continues after the player respawns.
Use it when
A workflow needs to reset a player after another in-game action.
Messages & Commands These blocks communicate with the ER:LC server or run in-game commands. Run Command Runs an in-game command. Input
Command : The command body that should be run in-game. Do not include the command prefix. Output
No direct output. The workflow continues after the command is sent.
Use it when
A workflow needs to run an ER:LC command that is not covered by a dedicated action block.
A server wants one workflow to trigger a custom in-game command.
Notes
Enter the command body only. Do not include a prefix such as ; or :.
Send Hint Sends a global hint message in-game. Input
Message : The global hint text to send. Output
Message : The in-game hint message that was sent. Use it when
A workflow needs to show a short server-wide notice, warning, or instruction.
Send Message Sends a global in-game message or announcement. Input
Message : The global message that should be sent. Output
Message : The in-game message that was sent. Use it when
A workflow needs to announce something to everyone in the ER:LC server.
A session event should notify players in-game.
Send Private Message Sends a private in-game message to a player. Input
Player : The player who should receive the private message.Message : The message that should be sent to that player. Output
Message : The private in-game message that was sent. Use it when
A workflow needs to notify one player without sending a server-wide message.
A staff action should explain what happened to the affected player.
Player State These blocks change a player’s in-game status or position. Heal Player Heals a player in-game. Input
Player : The player who should be healed. Output
No direct output. The workflow continues after the player is healed.
Use it when
A workflow needs to restore a player after an event, staff command, or support action.
Make Player Wanted Makes a player wanted in-game. Input
Player : The player who should be marked wanted. Output
No direct output. The workflow continues after the player is marked wanted.
Use it when
A workflow needs to apply wanted status after a rule, condition, or command is triggered.
Make Player Unwanted Removes a player’s wanted status in-game. Input
Player : The player who should be made unwanted. Output
No direct output. The workflow continues after the wanted status is removed.
Use it when
A workflow needs to clear wanted status after a staff action or condition passes.
Teleport Player Teleports a player to another player in-game. Input
Player : The player who should be teleported.Target : The player they should be teleported to. Output
No direct output. The workflow continues after the teleport runs.
Use it when
A workflow needs to move one player to another player.
A staff command needs to bring a player to a target location through another player.
Server Control These blocks affect the ER:LC server rather than one specific player. Shutdown Shuts down the in-game server. Input Output
No direct output. The workflow continues after the shutdown action is sent.
Use it when
A workflow needs to shut down the ER:LC server for a session ending, emergency, or staff action.
Start Fire Starts a fire in-game. Input Output
No direct output. The workflow continues after the fire is started.
Use it when
A workflow needs to create an in-game event or emergency scenario.
Stop Fire Stops all fires in-game. Input Output
No direct output. The workflow continues after fires are stopped.
Use it when
A workflow needs to clear active fires after an event, command, or session change.
Stop Dumpster Fire Stops the dumpster fire in-game. Input Output
No direct output. The workflow continues after the dumpster fire is stopped.
Use it when
A workflow needs to stop the dumpster fire without clearing every other fire.
Permissions These blocks change a player’s in-game staff permission level. Mod Player Promotes a player to moderator in-game. Input
Player : The player who should receive moderator permissions. Output
No direct output. The workflow continues after the player is promoted.
Unmod Player Removes moderator permissions from a player in-game. Input
Player : The player who should lose moderator permissions. Output
No direct output. The workflow continues after the player is demoted.
Admin Player Promotes a player to administrator in-game. Input
Player : The player who should receive administrator permissions. Output
No direct output. The workflow continues after the player is promoted.
Unadmin Player Removes administrator permissions from a player in-game. Input
Player : The player who should lose administrator permissions. Output
No direct output. The workflow continues after the player is demoted.
Add Helper Promotes a player to helper in-game. Input
Player : The player who should receive helper permissions. Output
No direct output. The workflow continues after the player is promoted.
Remove Helper Removes helper permissions from a player in-game. Input
Player : The player who should lose helper permissions. Output
No direct output. The workflow continues after the player is demoted.
Notes
Use permission actions carefully. They directly change a player’s in-game staff powers.
These actions are commonly paired with Discord or Melonly role checks.
Make sure the workflow only runs for trusted staff or automated systems.
Counts These blocks read player count information from the active ER:LC server so later blocks can use it. They require an active server session with at least one player online. Player Count Gets the current number of players in the ER:LC server. Input Output
Player Count : The current player count of the server. Use it when
A workflow needs to check if the server is full, empty, or above a certain player threshold.
Team Counts Gets the current number of players on each ER:LC team. Input Output
Civilian Count : The current number of players on the civilian team.Police Count : The current number of players on the police team.Sheriff Count : The current number of players on the sheriff team.Fire Count : The current number of players on the fire team.DOT Count : The current number of players on the DOT team.Jail Count : The current number of players on the jail team. Use it when
A workflow needs to make decisions based on team balance or team activity.
Working With ER:LC Actions ER:LC actions rely on your ER:LC integration being connected and able to reach the live server. ER:LC actions and ER:LC data blocks require at least one player to be in the server before they can execute.
When using ER:LC actions, consider:
Live Players : Player actions need the target player to be online in the ER:LC server when the workflow runs.Server State : ER:LC actions and count blocks need an active server session with at least one player online.Permissions : If a workflow can kick, ban, jail, run commands, or change staff permissions, add permission checks so only the right users can trigger it.Data Flow : Use trigger inputs, command options, or previous block outputs to choose the correct player, message, or target.
Example Workflow Flow
A staff member runs a custom slash command with a player and reason.
The workflow checks if the staff member has permission to use the command.
If allowed, the workflow sends the player a private in-game message.
The workflow kicks the player and creates a Melonly log.
Need help? Still have questions? Join our Discord server for support.
Last modified on June 29, 2026
