Skip to main content
These pages describe the v1.1 candidate implementation. V1.1 has not been formally released. Runtime, SDK and example availability depends on the actual files in the matching GitHub Release or Packages version. The download page continues to show public releases. Compatibility follows actual verification of pinned builds.

​
Choose a topic

Existing getting started, trading, wallet and GUI configuration pages retain their version-specific instructions. Prepare a fresh v1.1 installation below; consult backup and migration before using existing data.

​
New and shared installations

V1.1 primarily targets fresh installations, using market protocol 5, database schema 2 and item snapshot format 2. After obtaining matching release artifacts:
  1. Select one runtime JAR for the game’s version and JVM, using an independent server and plugin data directory.
  2. Use a new SQLite file for one node or a dedicated empty MySQL/MariaDB database for a shared market. Retain existing directories and databases; do not clear an old market to install a new one.
  3. Start once to generate configuration, stop normally, then fill in your license, network, node and economy settings. Retain the release defaults for product ID, license endpoint and trusted public key.
New installations use a durable SQLite file in the plugin directory for one market node. Shared markets use MySQL/MariaDB; multiple game nodes must not concurrently write the same SQLite file. New defaults do not replace an existing database connection with an empty database. Stop normally or use a consistent backup method for SQLite. Copying only .db from a running WAL database is insufficient. Each node keeps a unique network.node-id. Market identity, game version, item profile and currency identities must remain consistent. A failed database connection reports unavailability rather than substituting another market.

​
Existing v1.0 markets

V1.1 does not promise a direct JAR replacement or seamless upgrade. Back up the full original database, plugin directories, original JARs, player/world data and economy-provider data. Check migration, assets and recovery on an independent copy before deciding to switch the original environment. The candidate retains legacy-schema checks, pre-migration backups, old-node fencing and asset-recovery protections. Those mechanisms do not replace complete verification of an existing environment. Do not mix builds, delete the database, change currency identities or overwrite an old market with fresh defaults. Keep original backups and evidence, and follow migration and rollback guidance.

​
Interfaces and integrations

The base plugin provides a complete vanilla GUI. Developers can build their own ItemsAdder interfaces through configuration and the public Java SDK. Those interfaces use the host’s real items, protected actions, permissions and trading confirmations. ItemsAdder, Oraxen, Nexo and MMOItems identities come from real public APIs. Bridges and declarative rules do not relax item fidelity. Actual API availability and verification records govern compatibility.

​
Scoreboards, NPCs and permission plugins

Optional integrations provide display values and entry points. Verification records govern specific supported builds. Missing or incompatible APIs disable only their integration; the base market remains usable. Wallet placeholders use a short-lived cache. Unready services, expired caches and failed queries return empty values rather than invented zeros. Displays must not authorize payments or prove success, and NPC entry retains permissions and confirmation.

​
Enable only the trading modes you need

market.enabled-types defaults to BUY, SELL and AUCTION. To enable auctions alone:
The home page, publication, commands and SDK enforce the same setting. Any nonempty subset is valid; unknown types and an empty list are rejected. New trades follow the reloaded setting. Existing orders retain cancellation, expiry settlement and claims, so disabling auctions does not strand a winning bidder’s held funds.

​
Uncertain outcomes

Deposits, withdrawals, claims, bulk publication and administration have separate results. One successful operation does not prove that another succeeded, and a successful row does not make a whole batch successful. For UNKNOWN, retain the original operation and follow outcome review. A current balance or inventory screenshot alone cannot prove a historical external effect. Do not repeat debits or grants. Risk scores and cloud advice cannot confirm transaction outcomes.