🚀 Basic Configuration
You've installed the plugin and created your first chamber. Now let's tune the basics to match your server's playstyle. This is a quick-start guide—for deep dives, check the full config.yml reference.
The Three Settings You'll Change First
1. Reset Interval
How often should chambers reset?
global:
default-reset-interval: 172800 # 48 hours in secondsDefault: 48 hours (2 days)
Common values:
Daily:
86400(24 hours)Twice daily:
43200(12 hours)Weekly:
604800(7 days)Every 6 hours:
21600(for high-activity servers)
How to choose:
High activity server (50+ players): 12-24 hours
Medium activity (20-50 players): 24-48 hours
Small/casual (<20 players): 48-168 hours
Start longer, shorten later! It's easier to speed up resets than deal with player complaints about too-frequent changes.
2. Vault Cooldowns
How long before a player can loot the same vault again?
Default: 24 hours (normal), 48 hours (ominous)
Philosophy:
Normal vaults = more common, shorter cooldown
Ominous vaults = better loot, longer cooldown
Suggestions:
Match chamber resets: If chambers reset every 24h, set cooldowns to 24h
Independent progression: Cooldowns longer than resets = players can't farm same vault repeatedly
Fast-paced: 6-12 hours for active servers
Hardcore: 72+ hours for scarce loot
Example setups:
Fast-paced server:
Balanced server:
Hardcore server:
3. Protection Settings
Should players be able to break/place blocks in chambers?
Recommended settings:
Survival server (prevent griefing):
PvP/competitive server:
Creative/build server:
Don't disable protection on public survival servers! Players will grief your chambers. Use tcp.bypass.protection permission for staff instead.
Tweaking Loot
Your loot tables live in loot.yml, not config.yml. Here's a quick example:
What this means:
Each vault gives 3-5 random items from the loot pool
Higher rolls = more items per vault
Quick adjustments:
More generous:
More challenging:
For detailed loot customization, see the loot.yml reference.
Performance Tuning
If you have large chambers or many players, tune these:
blocks-per-tick controls reset speed:
Low (250-500): Slower resets, less lag
High (1000+): Faster resets, possible lag spikes
When to adjust:
Dedicated server with good CPU: Increase to 1000+
Shared hosting or budget VPS: Keep at 250-500
Massive chambers (50k+ blocks): Lower to 250 to avoid lag
Test it:
Watch for lag. Adjust blocks-per-tick and test again.
Reset Warnings
Players inside chambers get warnings before resets:
Default: Warnings at 5 minutes, 1 minute, 30 seconds before reset
Adjustments:
More warnings:
Fewer warnings (less spam):
No warnings (surprise resets):
Visual & Sound Settings
Make vaults more noticeable with particles and sounds:
Want to disable visual feedback?
Want more subtle particles?
See Spigot's Particle enum for all options.
Statistics Settings
Track player activity and leaderboards:
Disable statistics (saves minimal database overhead):
Show more players on leaderboards:
Update leaderboards more frequently:
Database Settings
SQLite (default, recommended for single servers):
No other settings needed! Everything is stored in data.db.
MySQL (for networks with multiple servers):
Database changes require a full restart, not just /tcp reload!
When to use MySQL:
Running BungeeCord/Velocity with multiple servers
Need shared chamber data across servers
Want external database access
Otherwise, stick with SQLite. It's faster and simpler for single-server setups.
Config Templates
Casual Survival Server
Philosophy: Generous cooldowns, peaceful gameplay, daily resets.
Competitive/PvP Server
Philosophy: Frequent resets, PvP enabled, competitive stat tracking.
High-Activity Server
Philosophy: Fast resets, short cooldowns, optimized for many players.
Roleplay/Immersive Server
Philosophy: Scarce resources, minimal UI feedback, long cooldowns for meaningful loot.
Applying Your Changes
Edit
plugins/TrialChamberPro/config.ymlSave the file
Reload:
/tcp reload
Most settings apply immediately. Exceptions:
Database settings require a full restart
Chamber-specific intervals affect new resets, not current timers
Backup before major changes! Copy your plugins/TrialChamberPro/ folder before experimenting with config.
Common Questions
"Do I need to restart after editing config?"
Usually no — /tcp reload works for most settings. Only database changes require a restart.
"Can different chambers have different reset intervals?" Yes. You can manage your chambers in-game.
"What happens to existing cooldowns if I change vault cooldown hours?" Existing cooldowns aren't retroactively changed. New cooldowns apply to future vault interactions.
"Can I disable per-player loot?"
Yes, set vaults.per-player-loot: false. Vaults become first-come-first-served like vanilla.
"How do I make chambers reset faster without lag?"
Increase blocks-per-tick gradually (500 → 750 → 1000) and test for lag. Also ensure async-block-placement: true.
Next Steps
Now that you've configured the basics, dive deeper:
Complete reference for every config option.
Customize what players get from vaults.
Change all player-facing messages to match your server's style.
Deep dive into how resets work and advanced scheduling.
💡 Pro Tips
Test in a dev environment first! Create a test chamber and experiment with settings before applying to production.
Watch your server TPS during resets. If TPS drops significantly, lower blocks-per-tick or increase reset-warning-times to spread resets out.
Join the discussion! Check GitHub Issues for community config tips and common setups.
Happy configuring! ⚙️
Last updated