BatchCommands config.yml - The Annotated Edition
Welcome to the operator's manual for your new reality-bending machine. This file is where you tune the engine, sharpen the blades, and hopefully, add the safety guards. Below is not just what each setting does, but the technical sorcery behind it.

execution
This section dictates the very soul of your scripts: who runs them, and how forgiving they are when things inevitably go sideways.

• default-executor
  • Description: Decides which poor soul gets blamed for running the commands.
    
    
  • Options:
    • CONSOLE: (Default & Sane Choice ) The all-powerful server console runs everything. Technically, the plugin calls Bukkit.dispatchCommand(Bukkit.getConsoleSender(), ...) for every command.
      
      
    • SENDER: (RISKY ) The player or command block that ran /filebatch is the executor. We simply grab the CommandSender object from the command event and pass it into Bukkit.dispatchCommand(). It's like giving the inmates the keys to the asylum—they can only open the doors they already had access to, but you're just asking for trouble.
  
  
• stop-on-error
  • Description: When a command fails, do we stop the whole show or just pretend nothing happened?
    
    
  • How it Works: Bukkit's dispatchCommand() method conveniently returns a boolean: true for success, false for failure (e.g., command not found, syntax error). When this is true, we simply refuse to schedule the next command in the sequence. The chain of execution just... stops.
    
    
  • Options:
    • true: (Default & Recommended) The responsible choice. Prevents your script from continuing its rampage after a critical failure.
      
      
    • false: (RISKY ) Ignores that false return value and plows ahead. For when you believe failure is just a state of mind.
  
  
• allow-op-commands
  • Description: The "Are You Sure?" switch. Blocks /op, /deop, etc., before they're even dispatched.
    
    
  • How it Works: A simple string check. Before we even think about dispatching a command, we peek at the first word. If it's "op" or "deop" and this setting is false, we reject it outright. No permissions check, just a flat "no".
    
    
  • Options:
    • false: (Default & Smart) Your server's political structure remains intact.
      
      
    • true: (EXTREMELY RISKY ) You've disabled the safety. If a player finds a way to run a script as console... well, it's been nice knowing you.
  
  
• command-blacklist
  • Description: A hardcoded list of forbidden words. Your last line of defense against typing stop instead of say stop.
    
    
  • How it Works: Same as the allow-op-commands check, but with a configurable list. If the command's first word is on this list, it's dead on arrival.

timing ⏱️
This is the real magic. Here's how we manipulate time itself for the !sleep decorator.

• ticking-mode
  • Description: Defines how the plugin perceives the passage of time. Is it the chaotic, lag-prone time of the Minecraft world, or the cold, precise time of the machine?
    
    
  • Options:
    • WORLD: (Default) The "vanilla" way.
      • Translation: When you write !sleep 5, the plugin performs this math: . It then tells the main server scheduler, "Hey, run the rest of this script in 100 ticks" using Bukkit.runTaskLater().
        
        
      • The Catch: If your server's TPS (Ticks Per Second) drops to 10, that "100 tick" delay will now take 10 real-world seconds. Your timing is now a lie.
    • INTERNAL / CLOCK: (Highly Recommended ✨) The "Swiss watch" method.
      • Translation: When you write !sleep 5, the plugin completely ignores Minecraft ticks. It calculates 5 seconds × 1000 milliseconds/second = 5000 milliseconds. It then hands this off to a separate, high-precision Java ScheduledExecutorService—a timer running on its own thread, completely outside the main server loop.
        
        
      • The Catch: There isn't one, really. This timer uses the system's clock, so it's immune to TPS lag. After exactly 5000 milliseconds, the executor's only job is to tap the main server thread on the shoulder and say, "Okay, you can run the next command now," safely pushing the execution back into Bukkit's world. This is how we get perfect precision without breaking the server.

scripting & lint-engine ✍️
These settings are less about raw power and more about defining your personal "dialect" of the scripting language. They control the syntax and validation, customizing the user experience for both you in-game and anyone using the web linter. At their core, they work via simple string comparisons to define what "valid" syntax looks like before the execution engine even has to think about it. This pre-processing step is what allows the linter to give you instant feedback.

The scripting block lets you change the very grammar of your files. Maybe your chat plugin already uses ! for a global channel, causing conflicts. No problem—change the decorator-char to $ or & and carry on. Are you a Python purist who can't stand seeing # used for anything but comments? You can enforce that here. These settings are instantly reflected in the web linter, so your entire toolchain adapts to your preferences.

The lint-engine block, meanwhile, is your personal QA department. The engine-mode lets you choose your safety level. BEFORE is the paranoid parent, checking the entire script for any possible issue before running a single line. It's perfect for production. AS_WE_GO is the cool uncle, letting the script run wild and only stepping in when it's about to cause a problem. It's faster for quick tests where you only need the first few lines to work.