-
Notifications
You must be signed in to change notification settings - Fork 25
Description
Description
At the moment, there is no direct or reliable way to determine whether a specific event is currently running.
In practical scenarios, this becomes a limitation when implementing server-wide or global activities that should only start once. For example, if an event is triggered multiple times in a short period, the system has no built-in mechanism to prevent duplicate executions.
The current workaround requires developers to manually manage the event state by creating a custom INTEGER variable using ServerVariables. This variable is then used as a flag or counter to indicate whether the event is active.
This manual approach requires developers to:
- Increment or set the value when the event starts
- Decrease or reset the value when the event finishes
- Add conditional checks before execution to prevent duplicate triggers
While functional, this solution introduces unnecessary complexity and increases the risk of logic errors, forgotten resets, or inconsistent states.
Problem
There is currently no built-in method to answer a simple but critical question:
“Is this event already running?”
Because this capability is missing, developers must rely on manual variable management solely to prevent duplicate execution. This not only increases development overhead but also makes configurations harder to maintain and debug.
In environments with frequent triggers or concurrent conditions, the lack of an official running-state check can also lead to race conditions, overlapping executions, or unintended behavior.
Current Limitation
ConditionalEvent includes a one_time option, which may appear related, but it does not solve the core problem.
Limitations of one_time:
- It does not support scope control similar to ServerVariables (e.g., GLOBAL vs PLAYER)
- It permanently disables the event after execution, making it unsuitable for reusable activities
- It cannot be used to dynamically check whether an event is currently active
Because of these constraints, one_time cannot be used in cases where:
- An event should run only once globally at a time
- An event needs to be reusable after completion
- The running state must be checked dynamically during runtime
Suggested Solution
Introduce a built-in mechanism to detect the running state of events.
PlaceholderAPI Support
%conditionalevents_running_<event>%
Behavior:
- Returns
trueif the event is currently executing - Returns
falseif the event is not running
This placeholder should reflect the real-time execution state of the event and work similarly to existing variable-based logic, but without requiring manual management.
Benefits
- Prevents duplicate event execution without custom variables
- Eliminates the need for manual counters or state flags
- Simplifies configuration and reduces developer workload
- Improves reliability and reduces bugs caused by overlapping executions
- Helps avoid race conditions in high-frequency trigger environments
- Provides a clean and standardized way to manage runtime state
- Aligns with existing concepts such as scoped variables and runtime checks
Example Use Case
Server-wide activity flow:
- First trigger → Event starts
- While the event is running → Additional triggers are blocked
- After the event finishes → The event becomes available again
This ensures that the activity runs only once at a time without requiring manual state tracking.
Summary
Adding a built-in running-state check would significantly simplify event management and improve system stability. It removes the need for manual state handling, reduces configuration complexity, and provides developers with a safer and more intuitive way to control global or reusable events.
Thank you.