/im Command - Complete Guide

The /im command (alias: /inviteme) handles all plugin administration tasks. This command is designed for server operators and admins.

Command Syntax

/im <subcommand> [options]

STATS - Server Statistics

Syntax

/im stats [N]

Permissions

invite.stats - Required (default: op)

Basic Statistics

/im stats

Output:

══════ Server Invite Statistics ══════
  Total invites given:    47
  Total invited players:  47
  ─────────── Top Inviters ───────────
  1. Alice — 8 invites
  2. Bob — 6 invites
  3. Steve — 5 invites
  4. Charlie — 4 invites
  5. Diana — 3 invites
════════════════════

Custom Top N

Show more or fewer entries in the ranking:

/im stats 10
/im stats 3

Example: /im stats 10 shows top 10 inviters instead of default 5.

Clear Player Stats

Reset all boost statistics for a specific player:

/im stats clear Alice

Permission: invite.admin (requires admin, not just invite.stats)

What gets reset:

Stat	Reset to
Boosted vanilla XP	0
Boost time (seconds)	0
Net boost XP	0
XP shared given	0
XP shared received	0

Use cases:

Fresh start after testing the boost system
Wipe stats at the beginning of a season or event
Remove erroneous or test data

When to Use

Monitor server growth and invitation activity
Find the most active community members
Decide who deserves VIP status based on activity

LOG - Action Log & Player Profiles

Syntax

/im log list [player-name] [N]
/im log export [global|player-name]

Permissions

invite.log - Required (default: op)

View Global Action Log

/im log list

Shows the last 20 actions by default (max: 200).

Output:

══════ Invite Action Log ══════
  [INVITE] Alice → Bob (2024-01-20 16:45)
  [UNINVITE] Admin → Charlie (2024-01-20 15:30) — rule violation
  [EXPIRED] Console → Tom (2024-01-19 12:00)
  [SYNC_ADD] Console → Eve (2024-01-17 20:30)
════════════════════

Custom Entry Count

/im log list 50
/im log list 100

Requests above 200 are automatically capped and a notice is shown.

View Player Profile

Passing a player name shows their full profile instead of the global log:

/im log list Alice

Output:

══════ Invite Profile: Alice ══════
  Invited by: Console (2024-01-01 10:00)
  Has invited: 3 players
    • Bob (2024-01-15 14:30)
    • Charlie (2024-01-17 09:00)
    • Diana (2024-01-19 20:15)
  ─── Recent Activity ────────────────
    [INVITE] Alice → Bob (2024-01-15 14:30)
    [INVITE] Alice → Charlie (2024-01-17 09:00)
══════════════════════════════════════

You can also limit the history shown:

/im log list Alice 10

Log Event Types

Type	Meaning
`INVITE`	Player was invited to the server
`UNINVITE`	Invitation was manually removed
`EXPIRED`	Temporary invitation expired automatically
`SYNC_ADD`	Player added during whitelist sync

Export to CSV

/im log export                  # full global log
/im log export global           # explicit global export
/im log export Alice            # export one player's log

Files created in plugins/InviteMe/logs/:

Global: global_log_YYYY-MM-DD_HHmmss.csv
Per player: user_log_<name>_YYYY-MM-DD_HHmmss.csv

CSV columns: timestamp, action_type, actor_name, actor_uuid, target_name, target_uuid, reason

Use cases:

Audit trail for rule violations
Report to server owner
Import into spreadsheet for analysis
Evidence when banning a player

SYNC - Synchronize Whitelist

Syntax

/im sync

Permissions

invite.admin - Required

What It Does

Forces an immediate whitelist synchronisation and reports the precise delta — no snapshot comparison, the count is calculated during the operation itself.

Output:

⟳ Starting whitelist synchronization...
→ Whitelisted: 47 | Tracked: 45 | Missing: 2
✓ Synchronization completed: 2 added, 0 removed
✓ All whitelisted players are tracked!

If players still need manual attention after sync:

⚠ 1 players still need manual attention

When to Use

After migrating from vanilla whitelist to InviteMe
After a server crash or plugin error
After manually editing whitelist.json
If players report they can’t join despite being “invited”

RELOAD - Hot Reload Configuration

Syntax

/im reload

Permissions

invite.admin - Required

What reloads:

config.yml — all settings including storage type, limits, LuckPerms config
Language files — all locale files in plugins/InviteMe/locales/
Permission group mappings — LuckPerms group-limits re-read
Access control mode — native vs plugin mode

What does NOT reload:

Active database connections (requires restart)
Cached player heads in GUI (refreshes on next open)

Workflow

After editing config.yml:

1. Edit plugins/InviteMe/config.yml
2. /im reload
3. /im debug  ← verify changes applied

MIGRATE - Move Data Between Backends

Syntax

/im migrate <sqlite|mysql|postgresql>

Permissions

invite.admin - Required

Validation

Before any data is touched, the command validates:

The target backend must be sqlite, mysql, or postgresql
The target must differ from the currently active backend

/im migrate badname
→ ✗ Unknown backend 'badname'. Valid options: sqlite, mysql, postgresql.

/im migrate sqlite   (when already on SQLite)
→ → Already using sqlite. No migration needed.

How Migration Works

Migration runs in 4 phases and reports progress for each:

/im migrate mysql

Output:

⟳ Connecting to MYSQL and migrating data...
  This may take up to 30 seconds — please wait...

⟳ [1/4] Verifying source data...
  Invitations: 47 | Logs: 120 | Stats: 35

⟳ [2/4] Migrating invitations...
✓ Invitations migrated (47 records)

⟳ [3/4] Migrating action log...
✓ Action log migrated (120 records)

⟳ [4/4] Migrating player stats...
✓ Player stats migrated (35 records)

✓ Migration complete! 202 records → mysql
→ Now change storage.type to 'mysql' in config.yml and run /im reload.

If a phase fails:

✗ Error in phase 2/4: <error message>
✗ Migration failed. Original data is intact.

After Migration

storage:
  type: mysql   # ← change this to the target backend

Then run /im reload to switch the active connection.

Safety Notes

Original data is never modified — /im migrate only copies records to the target backend
If migration fails at any phase, the copy is aborted and your source data is untouched
The .migrated suffix only appears during automatic startup migration (e.g. upgrading from the JSON backend), not when you run /im migrate manually
Always test migration with a backup first on large servers

DEBUG - Diagnostic Information

Syntax

/im debug

Permissions

invite.admin - Required

Full Debug Output

══════════ InviteMe Debug ══════════

1. Plugin Info:
  Version: 1.2.0
  Language: en
  LuckPerms: Enabled

2. Invite Statistics:
  Total Invites: 47
  Total Inviters: 12
  Max Invites (config): 5

3. Top Inviters:
  1. Alice — 8 invites
  2. Bob — 6 invites

4. Your Invite Info:          ← only shown when run by a player
  Has Unlimited: No
  Max Invites: 5
  Used Invites: 3
  Remaining: 2

5. PlaceholderAPI:
  Status: Installed

6. Mutual Boost Manager:
  Status: Enabled
  Your Boost Active: No
  Boost Partners: 1

7. Data File:
  Location: plugins/InviteMe/invites.db
  Exists: Yes
  Size: 68.00 KB
  Last Modified: 2024-01-20 16:45:00

  (Remote storage backends show "MYSQL (remote — no local file)" instead)

8. Whitelist Sync:
  Status: Enabled
  Total Whitelisted: 47
  Total Invites Tracked: 47
  Console Invites: 2
  Missing Invites: 0 (synced)
  Next Sync: 60 minutes

══════════════════════════════════════

Reading Debug Output

Section 4 only appears when executed by a player (not from console)
Data File section adapts to the active backend: SQLite shows invites.db, remote backends show the backend type instead
LuckPerms Enabled: group-limits in config.yml are active
PlaceholderAPI Installed: placeholders like %inviteme_count% work

Common Debug Scenarios

Players can’t join despite being invited:

/im debug
# Check: Access control mode correct?
/im sync

LuckPerms limits not working:

/im debug
# Check section 1: LuckPerms status
# If Disabled: verify LuckPerms is loaded before InviteMe
/im reload

BOOST - Boost Diagnostics & Overrides

Syntax

/im boost
/im boost status [player]
/im boost on [player]
/im boost off [player]
/im boost check <player1> <player2>

Permissions

invite.admin - Required

Full diagnostic and manual control over the mutual XP boost system.

Global Overview

/im boost

Lists every active boost pair server-wide and shows the multiplier.

Output:

⚡ Invite Boost — Global Status
  Manager: Enabled  Multiplier: 2x

  Alice ↔ Bob  [ACTIVE]
  Steve ↔ Diana  [ACTIVE]

  Total active pairs: 2

Player Status

/im boost status
/im boost status Alice

No player argument defaults to yourself (must be a player). Shows whether the target has an active boost and who their partners are.

Force-Activate / Clear Boost

/im boost on Bob       # force a test boost on Bob
/im boost off Bob      # clear the forced/active boost

Useful for verifying the system works without waiting for a natural mutual-invite scenario. The target player receives a notification. Run /im boost off <player> to remove it afterward.

Verify Invite Link

/im boost check Alice Bob

Checks whether a direct invite link exists between two online players (in either direction) and whether they are eligible for the boost.

Output:

⚡ Invite link check:
  Alice → Bob: Yes (Alice invited Bob)
  Bob → Alice: No
  Direct link exists: Yes (boost eligible)

Both players must be online. If either is offline the command reports “Player not found or offline.”

See the Mutual Boost Guide for the full mechanics.

Permission Summary

Permission	Grants Access To	Default
`invite.admin`	sync, reload, migrate, debug, boost, uninvite, stats clear	op
`invite.stats`	`/im stats [N]` — view only	op
`invite.log`	`/im log list`, `/im log export`	op
`invite.*`	All of the above	op

Admin Workflow Example

New Player Investigation

1. /im log list SuspiciousPlayer
   → See who invited them, when, and full action history

2. /invite remove SuspiciousPlayer Rule violation
   → Remove if needed, with reason logged

3. /im log list
   → Confirm the action was logged

Server Maintenance Routine

1. /im stats
   → Weekly check of server activity

2. /im log export
   → Export logs for archiving

3. /im debug
   → Verify everything is healthy

4. /im sync
   → Fix any whitelist discrepancies (after updates)

Troubleshooting

“You don’t have permission for /im”

✅ You need invite.admin or op status
✅ Check: /im debug (if you can run this, you have admin)

“Migration failed”

✅ Check database credentials in config.yml
✅ Verify the target database exists and is reachable
✅ Check firewall rules for the database port
✅ Original data is safe — check invites.db.migrated

“Reload didn’t apply my changes”

✅ Check for YAML syntax errors in config.yml
✅ Use a YAML validator online if unsure
✅ Run /im debug to confirm current values

Next Steps

📖 Player commands: /invite Command Guide
⚙️ Configuration: Config Reference
🔗 LuckPerms: LuckPerms Integration
📊 Storage: Storage Backends Guide