Command Execution Examples
Below, you'll find demonstrations of how different commands are processed and visualized within a system using a Velocity network framework. This setup includes two backend servers: lobby and hub. To reload the configuration, use cb reload or commandbridge reload.
Delayed Commands
This section illustrates the handling of delayed commands within the system. Commands can be scheduled for later execution using the scheduler, where the delay is specified in seconds. In this example, the command is set to execute after a 3-second delay. The execution takes place on the lobby server, with other configurations disabled.
Multiple Commands
This animation demonstrates the execution of several commands in sequence, each set to execute immediately with no delay. These commands are processed on the lobby server, executed in the exact order as defined in the configuration file. This example highlights the system's ability to handle multiple, simultaneous command executions efficiently.
Multiple Commands with Delay
This animation showcases the execution of multiple commands with specified delays between each. It highlights how commands are strategically scheduled over time to ensure orderly processing. The commands are configured to run on the lobby server, with non-relevant configurations disabled for clarity. Each command is executed in the order specified in the configuration file, but only after the designated delay has elapsed, demonstrating the system's capacity to manage timed operations effectively.
Player is not on target Server
This example shows the system response when a player attempts to execute a command but is not currently located on the target server.
You can disable the check by changing the following config to true:
Timeout Reached for Waiting
This image illustrates the system's behavior when a command, awaiting a player's action, reaches its timeout limit. Implementing a timeout is crucial for maintaining server performance; without it, commands waiting for offline players could indefinitely delay execution, only ceasing if the server shuts down. This setup ensures that operations do not hang and system resources are managed efficiently. 
Wait until player is on target Server
This example demonstrates the system waiting for the player to be detected on the target server (in this case the server hub) before executing further commands.
Wait until Player is Online - Console Perspective
This animation displays the console's viewpoint as it waits for a player to come online before executing commands. The console will provide detailed feedback on the status of the command and the player's connectivity only if the VerboseLogging feature is enabled. This feature is essential for troubleshooting and ensures transparent communication about command processing delays and player availability.
Disable Player Check
For scenarios where it is necessary to bypass the check determining if the executor is a player, the following configuration can be used:
This revision clarifies the purpose and application of disabling player checks, making it relevant for situations involving alternative executors like consoles or NPCs.