Admin Guide
This page covers day-to-day operations for server administrators running DynaTrade. It explains how to monitor the economy, apply configuration changes safely, respond to problems, and understand the server console output.
Monitoring the economy
First check: /dt status
This is your primary health command. Run it any time you want a quick overview of the economy engine.
/dt status
A healthy output looks like this:
Second check: /dt diagnose
After /dt status confirms the runtime is healthy, run /dt diagnose to see which items need attention.
/dt diagnose
This lists only items with active diagnostic flags, making it easy to spot unusual activity at a glance:
[Diagnose] 3 items flagged
IRON_INGOT [WARN VREF_DRIFT, WARN LOW_PARTICIPATION]
COPPER_ORE [WARN HIGH_VOLATILITY]
WHEAT [INFO NO_RECENT_ACTIVITY]
Healthy items are omitted. The output is capped at 10 items to keep chat readable. If more items are flagged, the header tells you the total count.
Item drill-down: /dt item <item>
When /dt diagnose points to a flagged item, inspect it in detail:
/dt item IRON_INGOT
Full output example:
-- Item -- Iron Ingot [WARN VREF_DRIFT, WARN LOW_PARTICIPATION]
-- Current --
Price: $12.40
Buy Price: $13.02
Sell Price: $11.78
Trend: bullish
VREF: 128.00 / 32.00 (4.00x)
Limits: $0.20 - $15.00
-- Calibration --
State: CALIBRATED
Reason: CALIBRATED
VREF: 128.00 / 32.00 (4.00x)
Samples: 8 / 5
History: 8 / 8
Max Change Cap: yes
Max Multiplier Cap: no
Configured Floor: no
Last Updated Cycle: 47
-- Last Cycle --
Price: $11.90 -> $12.40 (+4.2%)
Buy Count: 96
Sell Count: 12
Trigger: volume
-- Pressure --
Raw Pressure: +2.63
Adjusted Pressure: +0.74
Participation: 0.28
Players: 2
The output separates current live state from the last completed cycle. Lines that depend on cycle data (Last cycle, Pressure, Note) are omitted when no cycle has completed yet — after restart, for example.
[DynaTrade] -- Status --
[DynaTrade] [SYS] Economy: OK
[DynaTrade] [SYS] Scheduler: active
[DynaTrade] [TIME] Next cycle: 03m 12s
[DynaTrade] [DATA] Generation: 47
[DynaTrade] [DATA] Items: 32
[DynaTrade] [DATA] Pending signals: 4
[DynaTrade] [PRICING] player-aware-pressure: target=6 minParticipation=0.35 activeReachEnabled=true minActiveReach=0.40 reachWeight=0.25
[DynaTrade] [PRICING] last cycle player participation data seen: true
[DynaTrade] [SYS] Checkpoint: none (no pending recovery)
[DynaTrade] [SYS] Storage: healthy (last write OK)
| Field | What to look for |
|---|---|
| Economy | Should be OK. If not, Vault or the economy provider is unavailable. |
| Scheduler | Should be active. If stopped, the market is not updating. |
| Next cycle | Confirms the scheduler is firing normally. |
| Generation | Increments by one each cycle. A stale number after a long session may indicate a scheduler problem. |
| Pending signals | The number of trades waiting for the next cycle. Normal to see a non-zero value between cycles. |
| player-aware-pressure | Shows the current player-aware pricing normalization settings that scale dominant-side pressure. |
| last cycle player participation data seen | true means the last processed cycle observed participation data. false usually means no qualifying participation signal was present in that cycle. |
| Checkpoint | Should normally show none. A checkpoint present on startup means DynaTrade recovered a prepared cycle — this is expected after a crash. |
| Storage | Should be healthy. |
If /dt status instead prints a degraded-state warning and stops there, the
plugin no longer has an active runtime. Trades are unavailable and a full
server restart is required.
Checking a specific item: /dt item <item>
/dt item DIAMOND
Use this to answer player questions about a specific item's price, trend, or limits.
[DynaTrade] -- Item -- Diamond
[DynaTrade] [PRICE] Current price: $148.20
[DynaTrade] [PRICE] Buy: $157.09 | Sell: $133.38
[DynaTrade] [DATA] Trend: up
[DynaTrade] [DATA] Limits: $45.00 - $1200.00
Optional quote-layer check: /dt pricingstatus
Use this only when you are evaluating the optional momentum-driven quote-adjustment layer rather than the base market price itself.
It shows:
- whether the optional momentum-spread layer is enabled
- the current
tau-*andk-*runtime values - up to
10item momentum values with warmup state
If you are not using the optional quote-adjustment layer, you can ignore this command safely.
Applying configuration changes
Safe reload flow
- Edit
config.yml,items.yml, or a language file. - Run
/dt reload. - Run
/dt status— confirm the economy isOKand the scheduler is running. - Test affected items with
/price <item>or/market. - In
/market, spot-check the current public flow: hub, Explore listing, Insights, and one item detail screen.
/dt reload preserves the current in-memory market state. Prices are not
reset. The reloaded configuration takes effect for the next cycle and any new
trades.
Operationally, reload now does more than just rebuild config:
- it closes new trade admission first;
- drains in-flight apply and durability work for up to about 3 seconds;
- persists the old runtime before stopping it;
- stops the old runtime completely before creating the replacement runtime;
- keeps the old runtime if the failure happens before the stop boundary;
- enters degraded mode if the failure happens only after the old runtime was already stopped.
If you change apply.max-per-tick or apply.drain-deadline-ms, treat that as an operational tuning change. Reload applies it immediately, but you should still validate the result during a staged or real load test before leaving it in production.
When to use reload vs. restart
| Situation | Use |
|---|---|
Editing config.yml or items.yml |
/dt reload |
| Updating the language file | /dt reload |
| Adding or removing items | /dt reload |
| Updating the DynaTrade jar itself | Full server restart |
| Recovering from a broken or degraded runtime | Full server restart (preferred) or /dt reset when the runtime still exists |
Adding an item mid-session
You can add items to items.yml while the server is running:
- Add the item entry under
items:. - Run
/dt reload. - Test with
/price <NEW_ITEM>.
The new item will start at its configured base price and begin accumulating market pressure immediately.
Removing an item mid-session
- Remove the item entry from
items.yml. - Run
/dt reload.
Current reload behavior is more conservative than a hard discard. If valid pending signals for the removed item still exist during reload, DynaTrade can preserve the legacy item definition long enough to recover that pending work safely. After that recovery window, the removed item no longer appears in the GUI or responds to commands.
Forcing a market cycle
/dt cycle
Forces an immediate cycle outside of the normal schedule. All pending buy and sell pressure is processed and prices are updated.
When to use this: - You want to test the effect of recent trades without waiting. - You are running a controlled test scenario and need deterministic timing. - You want to give players updated prices after a planned market event.
Forcing a cycle does not reset the scheduler. The next automatic cycle still runs at the normal interval after the forced one.
Resetting the market
/dt reset
This is a destructive operation that wipes all dynamic price history and resets the market to base prices from items.yml.
Before running reset:
- Confirm this is what you intend. It cannot be undone.
- Back up plugins/DynaTrade/market-state.yml if you want to preserve the current state.
Reset flow:
1. Run /dt reset — a confirmation token is displayed.
2. Run /dt reset <token> within 60 seconds to confirm.
3. DynaTrade clears buffers, deletes recovery files, and rebuilds a clean market state from items.yml.
4. The scheduler resumes automatically.
After reset:
- Run /dt status to confirm the economy is back to OK.
- Confirm generation is now 0 or 1.
- Test with /price and /market.
Reading the server console
DynaTrade logs to the server console at key events. Learning to read these logs quickly makes monitoring much easier.
Startup
[DynaTrade] [scheduler] started interval=6000t (300s)
[DynaTrade] [runtime] commands registered.
[DynaTrade] [startup] plugin enabled version=0.8.6 language=en template=BALANCED templateOverrides=2 economy=ready restoredItems=32 restoredSignals=3
A clean startup shows: the scheduler started, commands registered, and the startup summary reported the restored item/signal counts.
Cycle summary
[DynaTrade] [cycle] generation=42 trigger=TIME items=5 processed=5 buyVolume=320 sellVolume=110 totalVolume=430 status=OK
One line per cycle. This is the normal runtime heartbeat. Confirms how many items were priced and the direction of the cycle.
Trade apply backpressure
The current 0.8.6 line uses bounded main-thread apply draining for durable trades.
apply:
max-per-tick: 8
drain-deadline-ms: 15
Practical guidance:
- keep these defaults unless you have your own benchmark evidence
- raising
max-per-tickmay improve throughput on some machines - raising it too far can bring back tick pressure during bursts
- lowering the cap or deadline can be gentler on the server, but may increase backlog during heavy trading
Warnings
[DynaTrade] [pending] pending signal payload is missing 'signals'; quarantining payload.
A quarantined recovery file means DynaTrade found something it could not read safely and moved it out of the active recovery path instead of crashing. This is an expected defensive behavior after a hard crash or a failed manual edit.
Errors
[DynaTrade] [startup] blocking startup because market-state.yml is invalid.
This is a fail-safe condition. DynaTrade has detected that the primary state file is unreadable or structurally broken and has refused to start with potentially corrupted data. See Troubleshooting for the recovery procedure.
File reference
| File | Edit it? | Purpose |
|---|---|---|
config.yml |
Yes | Global economy configuration |
items.yml |
Yes | Item catalog and per-item tuning |
languages/messages_en.yml |
Yes | English player-facing text |
languages/messages_pt.yml |
Yes | Portuguese player-facing text |
market-state.yml |
No | Authoritative persisted market state |
pending-signals.yml |
No | Pending trade signal snapshot |
pending-signals.log |
No | Accepted trade journal (append-only) |
cycle-checkpoint.yml |
No | Write-ahead checkpoint for crash recovery |
trade-runtime-state.yml |
No | Staged prepared-trade runtime retry state |
pending-deliveries.yml |
No | Pending, partial, manual-review item deliveries, plus pending Vault-credit obligations |
Pending delivery incidents
MANUAL_REVIEW means the inventory may already have changed and DynaTrade cannot prove the final outcome. It is intentionally excluded from automatic retry.
Do not change MANUAL_REVIEW to PENDING on a running server. Stop the server, back up the file and logs, and verify player inventory/economy evidence before manual resolution.
REFUND_FAILED means a sell compensation could not be persisted. Record the operation ID, player UUID, item, quantity, and reason; fix storage or capacity first; then verify that compensation was not already delivered before taking manual action.
If the console reports degraded mode after /dt reload, do not keep issuing
trade commands. The old runtime is already gone and a restart is required to
rebuild the runtime safely.
See Trade Consistency and Recovery for the complete procedure.
Permission delegation
DynaTrade uses two admin permission nodes intentionally. This lets you give staff diagnostic access without the ability to wipe the economy.
| Permission | What it enables |
|---|---|
dynatrade.admin |
Status, item inspection, diagnose, pricingstatus, reload, manual cycle |
dynatrade.admin.reset |
Full market reset (destructive — give to owners only) |
Recommended admin routine
| Frequency | Action |
|---|---|
| After every configuration change | /dt reload, /dt status, spot-check one item with /dt item |
| After a crash or unexpected restart | Check startup logs, run /dt status, confirm generation advanced correctly |
| When players report wrong prices | /dt item <item>, compare to items.yml base price and limits |
| When the economy feels stuck | /dt status to check scheduler, /dt cycle to force a cycle if needed |
| Before a planned economy wipe | Back up market-state.yml, then run /dt reset |