Verlihub Lua Script Library 🇬🇧 🇨🇳 🇮🇳 🇪🇸 🇨🇿 🇩🇪 🇳🇱 🇫🇷 🇮🇹 🇵🇱 🇷🇴 🇷🇺

This library collects Lua scripts written for Verlihub hubs. Each script adds one small hub feature without changing the Verlihub C++ source or compiling a custom plugin.

Use these articles for display bots, helper commands, timed messages, user-list entries, validation helpers, and small automation. Keep heavy work outside the hub process and use Lua only for the hub behavior that must run inside Verlihub.

Purpose Of This Library

The library exists so a hub owner can review a script, understand what it changes, copy it into the expected directory, adjust the documented settings, load it, test it, and disable it again without guesswork.

Each script article should state:

• What the script does.
• Which Verlihub feature it changes or adds.
• Whether it creates a bot, command, timer, hook, user-list entry, or validation helper.
• Where the script file should be placed.
• How the script is loaded, reloaded, unloaded, or disabled.
• Which settings are safe to edit.
• Which Verlihub plugin or hub permission the script depends on.
• Known limits, version notes, and production warnings.

Recommended Script Standards

Scripts in this library should stay small, readable, and version controlled. One Lua file should do one job. Do not mix a clock bot, rules command, anti-spam check, and database cleanup into one file unless the article explains why those actions must ship together.

• Use one main purpose per script.
• Place clear comments at the top of the file.
• Group configurable values near the top.
• Do not hardcode private paths unless the article explains them.
• Avoid unnecessary database writes.
• Avoid blocking network calls from hub events.
• Avoid heavy loops inside login, chat, or user-list hooks.
• Make startup and shutdown behavior clear.
• Document load, reload, and unload commands.

For production hubs, smaller scripts are usually easier to debug, disable, and replace than one large file that controls unrelated hub behavior.

Suggested Script Header

Start each script with a short comment block. The header should tell the next operator what the file is before the script touches a live hub.

-- Script: time.lua
-- Purpose: Displays a clock-like bot entry in the Verlihub user list.
-- Scope: User-list display only.
-- Author: PWiAM
-- Notes: Test on a private hub before production use.

Suggested Script Article Format

Each child article in this section should use the same shape so scripts can be compared and reviewed quickly.

1. Overview.
2. Requirements.
3. Installation.
4. Configuration.
5. Loading the script.
6. Testing.
7. Unloading or disabling.
8. Troubleshooting.
9. Full script.
10. Related pages.

Installing Scripts

The exact location depends on the Verlihub install path, but custom Lua files should live in a directory owned by the service user that runs the hub.

sudo mkdir -p /usr/local/etc/verlihub/lua
sudo chown -R verlihub:verlihub /usr/local/etc/verlihub/lua
sudo chmod 750 /usr/local/etc/verlihub/lua

Then place each script in that directory:

/usr/local/etc/verlihub/lua/time.lua

If your service runs under a different user, change the owner to that account. Do not use chmod 777 /usr/local/etc/verlihub/lua. Lua files run inside the hub process, so write access belongs only to trusted administrators.

Loading And Reloading Scripts

Lua scripts require the Verlihub Lua plugin to be installed and enabled first. If the plugin is not loaded, review the parent Lua setup article before loading script files.

Useful plugin checks include:

• !pluglist
• !lstplug

Use a small-change workflow when editing a live script:

1. Save a backup of the current working file.
2. Change one setting or one function.
3. Reload only that script if your build supports it.
4. Check hub output and Verlihub logs.
5. Revert quickly if users see errors, duplicate bots, or repeated chat output.

If script reload commands are not available in your Verlihub build, restart or reload the Lua plugin according to your server's plugin management commands.

Testing Scripts Safely

Test Lua scripts on a private hub or quiet maintenance window before relying on them in production.

• Confirm the script loads without syntax errors.
• Confirm it does not flood main chat.
• Confirm it does not create duplicate bots or repeated user-list entries.
• Confirm it behaves correctly after reload.
• Confirm it behaves correctly after a hub restart.
• Confirm operators can disable it quickly.
• For command scripts, test with normal users and operator accounts.
• For timed messages or user-list entries, test the interval so the script does not create noise or load.

Production Safety Notes

Lua code runs inside the hub process. A bad script can affect chat, login, user-list updates, or plugin shutdown.

Avoid:

• Infinite loops.
• Long sleeps inside event handlers.
• Large file reads during user events.
• Blocking external HTTP requests.
• Heavy database queries from chat or login hooks.
• Repeated broadcast messages without limits.
• Scripts that cannot be unloaded cleanly.

Prefer:

• Small event handlers.
• Clear configuration values.
• Conservative timers.
• Simple command logic.
• Logging only when it gives an operator useful information.
• Easy rollback.

If a task is long-running, move it outside Verlihub and let Lua trigger or display the result.

Version Control

Keep custom scripts in Git when possible. A small repository in the script directory is enough for many hubs.

cd /usr/local/etc/verlihub/lua
git init
git add .
git commit -m "Initial Verlihub Lua scripts"

Before editing a production script, check what is already changed:

git status
git diff

After testing the change:

git add time.lua
git commit -m "Update time.lua clock display"

This gives the next operator a change history and a fast rollback path.

Available Scripts

time.lua Verlihub user list clock script creates a small bot-like user-list entry that displays the current time.

Use it when a hub wants a visible clock entry without running a separate bot process or external service. It is the first maintained example in this library and can be used as a pattern for other display-oriented scripts.

Adding More Scripts

New scripts should be added as child articles under this section, not pasted into this index page. Good candidates include:

• Welcome message script.
• Rules reminder script.
• Operator helper command script.
• Scheduled announcement script.
• User count display script.
• Anti-spam helper script.
• Hub information command script.
• Maintenance mode notice script.

Each new article should include installation notes, configuration values, test steps, unload steps, and the full script listing.