ChestShop tasks

Task guides and troubleshooting for ChestShop. Check the installed release before changing configuration or data.

Diagnose a ChestShop sign that does not become a shop

A sign that stays ordinary has failed before any customer payment. Check sign recognition, the linked chest and creation permissions instead of refilling stock or changing the economy balance.

Before you start

ChestShop connects a sign, stock container and economy account. Test the buyer and seller separately: permission to create a shop does not prove stock access or payment works. Read the installed release documentation before changing signs on public shops.

Work through the check

  1. Reproduce beside a single test chest using the sign layout shown by the installed ChestShop release.
  2. Check that the sign targets the intended container and that its owner line and item description follow the documented syntax.
  3. Use an ordinary permitted shopkeeper, watching chat and the server log for the first creation denial or item-parsing error.
  4. Compare another plain material and an unprotected test location to separate sign formatting from region, spawn or claim restrictions.

What to compare

Leave the failed sign text in your private notes before trying the corrected form. A screenshot can hide spacing or punctuation, so record each line exactly and compare it with the installed release instructions.

Confirm the result

The plugin should acknowledge shop creation and recognize the intended item and quantity. A customer should see a shop response when interacting with that sign.

If the result differs

An unknown item points to parsing or version support; a protection denial points to the creation location. A different sign plugin may intercept interaction, so retain the exact message.

Recover safely

Remove only the unsuccessful test sign after recording its details. Do not delete the shop database or disable all land protection to make sign creation succeed.

Documentation and related help

Check the ChestShop maintainer documentation and ChestShop maintainer reference against your installed release before applying changes.

Separate ChestShop buy and sell directions before opening a market

A two-way sign can be confusing because the player and shop owner see opposite money and item flows. Document each direction so a reversed price does not become a market exploit.

Before you start

ChestShop connects a sign, stock container and economy account. Test the buyer and seller separately: permission to create a shop does not prove stock access or payment works. Read the installed release documentation before changing signs on public shops.

Work through the check

  1. Create a private test shop with an inexpensive item, a counted stock amount and a recorded owner balance.
  2. Read the sign pricing syntax in the ChestShop documentation for your release and identify which price represents customer buying and selling.
  3. Have a non-owner buy one advertised bundle, then record the customer balance, owner balance and both item quantities.
  4. Reverse the transaction with one bundle and check that its amount and payout match the intended selling rule.

What to compare

Test both directions from the customer account with known starting stock. The owner’s perspective reverses who pays and who supplies items, which makes an untested buy or sell label easy to misread.

Confirm the result

The buy direction should move stock to the customer; the sell direction should move it back. Money should travel in the opposite direction for each accepted transaction.

If the result differs

If players profit by cycling the same bundle, compare both prices and bundle sizes with other server shops. Taxes may change the owner’s net amount, so inspect configured tax behavior too.

Recover safely

Close the test shop while correcting the sign. Reconcile the small controlled transactions before reopening; do not compensate every customer from an assumed price without checking actual trades.

Documentation and related help

Check the ChestShop maintainer documentation and ChestShop maintainer reference against your installed release before applying changes.

Check ChestShop quantity and item matching with renamed stock

A shop may contain the right material but still reject a trade because the expected item has different metadata or the container cannot supply the advertised bundle.

Before you start

ChestShop connects a sign, stock container and economy account. Test the buyer and seller separately: permission to create a shop does not prove stock access or payment works. Read the installed release documentation before changing signs on public shops.

Work through the check

  1. Copy one intended sale item into a test container and record its name, enchantments, damage and other visible properties.
  2. Use the installed ChestShop item-identification method rather than guessing an old numeric item ID.
  3. Count the advertised bundle and ensure the chest can supply that exact quantity without mixing different item variants.
  4. Try a normal item first, then the intended customized variant, recording which one the shop recognizes and transfers.

What to compare

Keep the original custom item outside the shop while preparing samples. Compare material, quantity and metadata separately, and do not rename live stock repeatedly just to see whether the shop begins accepting it.

Confirm the result

Only the documented matching item should move, in the advertised quantity. The customer should not receive a substituted or partially missing bundle.

If the result differs

A custom-item plugin may store data beyond the visible name. Check its ChestShop integration before accepting valuable custom gear, and confirm the customer has room for the whole transaction.

Recover safely

Keep the original stock and sign description available while testing a replacement entry. If matching remains uncertain, suspend that item’s shop instead of stripping item metadata or deleting inventories.

Documentation and related help

Check the ChestShop maintainer documentation and ChestShop maintainer reference against your installed release before applying changes.

Investigate a ChestShop out-of-stock message when the chest is full

A full chest does not prove it contains enough matching shop stock. Treat the displayed material, bundle quantity and linked container as separate checks before moving valuable items.

Before you start

ChestShop connects a sign, stock container and economy account. Test the buyer and seller separately: permission to create a shop does not prove stock access or payment works. Read the installed release documentation before changing signs on public shops.

Work through the check

  1. Confirm you are reading the sign for the container you opened, especially around double chests and closely packed stalls.
  2. Compare the sign’s item and bundle size with a counted stack of the exact intended item in the linked container.
  3. Repeat with a plain low-value item in a private test shop so custom metadata and other shop plugins do not obscure the result.
  4. Check the shop owner identity and server log for container-access, protection or item-conversion errors at the failed interaction.

What to compare

Count the exact item variant required by the sign, not the chest’s total occupied slots. A chest can look full while containing no stack that matches the configured sale item.

Confirm the result

A known matching bundle should permit one purchase and reduce the linked container stock by the advertised amount, with the expected balance changes.

If the result differs

If only renamed or enchanted stock fails, investigate item equivalence rather than capacity. If no stock works, inspect the sign link and protection integrations for that location.

Recover safely

Return test items to their recorded owner and leave the original shop stock intact. Recreate a sign only after documenting its owner, prices and item identity; do not bulk-remove market records.

Documentation and related help

Check the ChestShop maintainer documentation and ChestShop maintainer reference against your installed release before applying changes.

Audit ChestShop taxes with one low-value transaction

A seller receiving less than the displayed price may be paying a configured transaction tax. Measure the debit and credit around one trade before treating the difference as missing money.

Before you start

ChestShop connects a sign, stock container and economy account. Test the buyer and seller separately: permission to create a shop does not prove stock access or payment works. Read the installed release documentation before changing signs on public shops.

Work through the check

  1. Read the active ChestShop tax settings and any exemption permissions for the installed release; record the previous configuration.
  2. Choose a test seller and buyer with known balances, using the same economy backend and world as the affected market.
  3. Make a single purchase and compare buyer debit, seller credit and any documented tax-account movement.
  4. Repeat with an account that lacks exemptions, then compare a staff role only if your policy intentionally treats it differently.

What to compare

Include the shop owner, customer and any configured tax recipient in the balance record. A missing amount may be an intentional tax destination rather than a lost transfer between the two visible participants.

Confirm the result

The observed difference should match the configured tax calculation and destination. No unexplained second charge should appear when a menu or another plugin wraps the transaction.

If the result differs

Rounding, bundle size and permission exemptions can change the result. Avoid evaluating tax from a leaderboard or cached display; use the provider’s direct balances and transaction timestamp.

Recover safely

Restore the original tax rule if the trial does not match your policy. Correct only the verified test differences and review public pricing before applying a server-wide tax change.

Documentation and related help

Check the ChestShop maintainer documentation and ChestShop maintainer reference against your installed release before applying changes.

Test ChestShop inside a claim without granting build access to customers

A customer should be able to trade at a market without gaining permission to break containers or edit signs. Protection integrations need a customer test, not only a successful owner visit.

Before you start

ChestShop connects a sign, stock container and economy account. Test the buyer and seller separately: permission to create a shop does not prove stock access or payment works. Read the installed release documentation before changing signs on public shops.

Work through the check

  1. Write down the claim, region and shop owner, then confirm which protection plugins apply at that exact sign.
  2. Use the protection plugin’s documented shop integration or interaction rule instead of granting general build access.
  3. Have an unrelated normal account buy one item, then try opening the stock chest, changing the sign and breaking a nearby block.
  4. Repeat from the neighboring claim or region edge to check whether an overlap changes the result.

What to compare

Use a separate private chest beside the test shop as a protection control. Successful trading is only safe if the same customer still cannot open unrelated storage or edit the market structure.

Confirm the result

The customer should complete the trade while direct stock removal, sign edits and building remain restricted. The shop owner should retain authorized management access.

If the result differs

If the trade fails, read both ChestShop and protection messages for the same click. Spawn protection or a second claim layer can still deny interaction after one region flag allows it.

Recover safely

Restore the previous narrow interaction setting if the change grants unintended access. Keep the market closed until you can demonstrate trading and container protection with separate test accounts.

Documentation and related help

Check the ChestShop maintainer documentation and ChestShop maintainer reference against your installed release before applying changes.

Preserve ChestShop ownership when a shopkeeper changes name

A display-name change should not become a reason to hand stock or proceeds to another identity. Verify ownership using the records supported by your ChestShop release before editing a public shop.

Before you start

ChestShop connects a sign, stock container and economy account. Test the buyer and seller separately: permission to create a shop does not prove stock access or payment works. Read the installed release documentation before changing signs on public shops.

Work through the check

  1. Ask the owner to identify a specific shop and record its location, sign text, linked stock and player UUID.
  2. Check the installed ChestShop documentation for name updates and ownership handling; distinguish a name change from an authentication-mode or UUID change.
  3. Compare a harmless test trade before and after the owner reconnects, observing the actual recipient balance.
  4. If a documented repair action exists, rehearse it against a copied test shop and inspect both the sign and owner account afterward.

What to compare

Check both the old and new player names against the same authenticated UUID. A name resemblance does not justify reassignment, especially when cross-play plugins use different account mapping rules.

Confirm the result

The same legitimate account should retain shop management and receive proceeds. A different player reusing an old name must not gain ownership.

If the result differs

If the server’s authentication mode changed, stop and investigate identity migration across permissions, claims and economy. Renaming a sign alone cannot reconcile mismatched UUID records.

Recover safely

Keep the old shop record and consistent stock checkpoint while investigating. Do not transfer all shops or reset owner data until the current and former identities have been verified.

Documentation and related help

Check the ChestShop maintainer documentation and ChestShop maintainer reference against your installed release before applying changes.

Collect a ChestShop transaction failure without exposing player data

An intermittent market error needs a traceable shop and transaction. Record a small reproduction so support can distinguish stock movement, balance changes and protection denials.

Before you start

ChestShop connects a sign, stock container and economy account. Test the buyer and seller separately: permission to create a shop does not prove stock access or payment works. Read the installed release documentation before changing signs on public shops.

Work through the check

  1. Note the server build, ChestShop build, Vault provider, shop location and the exact sign layout without sharing unrelated player accounts.
  2. Choose a cheap item and controlled buyer, record both balances and quantities, then attempt one transaction at a known time.
  3. Capture the first relevant exception and surrounding log lines, including any protection or provider message for that same attempt.
  4. State whether the customer lost money, received stock, saw a rejection or observed only a stale display.

What to compare

Record one failed transaction time precisely enough to find its log entry. Share the error and plugin versions without publishing full databases, player inventories, payment histories or connection credentials.

Confirm the result

The report should show a repeatable transaction with enough before-and-after evidence to identify which step failed, without needing a full private server archive.

If the result differs

Redact addresses, database credentials and private chat before sharing logs. Keep the original exception text and stack trace structure so redaction does not remove the failing plugin name.

Recover safely

Suspend the affected shop if outcomes are inconsistent and preserve its stock and records. Avoid repeated purchases on live accounts while gathering evidence or applying unverified refunds.

CloudExa game console with the log controls visible.
The CloudExa console provides the log view used in this check. This is a general panel screenshot, not plugin-specific output.

Documentation and related help

Check the ChestShop maintainer documentation and ChestShop maintainer reference against your installed release before applying changes.