StrawIO 1.0.0 — upgrade from development builds

There are 33 products. All versions are 1.0.0 at the owner's request. Install only one readable or obfuscated JAR per product. Replace the suite together because owner API names changed. Never load both old and new identities.

Renamed products and data

Stop the server and take a separate backup first. These are operator instructions; development has not moved or modified production files.

Move the whole renamed folder, preserving data/license-installation-id, database files, outboxes, custom configuration and license. If both source and destination already contain data, do not merge/overwrite blindly: reconcile offline against a backup. Startup refuses an old sibling folder containing config.yml to prevent silently starting an empty database.

Update permission grants strawio.orders.* → strawio.order.*, strawio.bounties.* → strawio.bounty.*, and Worth use permission → strawio.sell.worth. Placeholder prefixes change from straworders_ → straworder_, strawbounties_ → strawbounty_. Ordinary plural command aliases such as /orders remain convenient aliases, not product identities.

Existing SQL table names and deterministic operation receipt prefixes are intentionally unchanged. Renaming durable operation IDs could replay fulfilled or paid transactions. They are compatibility data, not current product IDs.

Worth merge

Remove the separate StrawWorth JAR. /worth, its GUI, display preferences and optional ProtocolLib lore now belong to StrawSell. %strawworth_*% placeholders remain provided by Sell for compatibility.

Copy the saved StrawWorth/data/display-preferences.yml into StrawSell/data/worth-display-preferences.yml only if the target has no existing preferences. Conflicting preferences require an explicit per-player merge; do not discard either file. Compare customized prices/categories from both products before choosing the single Sell catalog. The shipped catalogs agree, but customer customizations may not. Move desired Worth config options under worth, language/presentation under their worth sections, and its GUI to gui/ItemPricesGUI.yml.

Customer setup

Each license.yml only needs key. Join the support Discord linked there for licensing. The panel must use the exact final Product ID listed in each product document. Port is detected automatically; installation UUID remains persistent. No customer key is tested from development.

Keep each existing plugin data folder when replacing its JAR. Customer-editable YAML is upgraded automatically with a three-way merge: new keys are added, unchanged old defaults move to the new defaults, and retired untouched defaults are removed. Values, lists and extra keys changed by the server owner are preserved. The prior default history is embedded inside the JAR, so this does not create another customer-facing settings file. Corrupt YAML is never overwritten; startup stops that product so the owner can repair the file. A backup before any server upgrade is still recommended.

This merge applies to config, storage, language, sounds, presentation, catalog and GUI YAML installed by the product. It does not rewrite player data, databases, license keys or custom values. GUI wording is edited directly in each GUI file; notification wording is in lang/.

Database settings are in storage.yml for new installs. An existing config.yml storage section takes precedence, preventing accidental database changes. Move that section manually only after comparing values. Use unique server-id values for shared MySQL mode and keep each server's outboxes separate.

Vault hooks its registered server economy automatically; for EssentialsX currency, enable EssentialsX and Vault. Vault is an adapter, not a currency store. No manual provider-verification flag is required. Other providers must support their own API's threading behavior; an uncertain payment is not retried automatically.

Reload and validation

Use /<pluginname> reload, e.g. /straworder reload, after ordinary file edits. Help is /<pluginname> help. Reload quiesces protected actions, closes owned inventories through player schedulers, drains storage asynchronously and revalidates the license. An exclusive file lease prevents overlapping storage owners on replacement.

Use a server restart for renames or JAR replacement. Generic PlugMan replacement has not been live-certified. On Folia, external synchronous unload cannot safely access inventories in other regions; the product reload command performs the asynchronous close while the plugin is still enabled. Do not treat compile/unit checks as proof of safe arbitrary live unloading or stable TPS.

Update API remains a stub; this does not block activation. Console reports Running, warnings or activation failures; it does not claim Latest without a real update response.

Unified files and new products

Fresh installations use gui/ directly, one presentation, and no theme selector or commands.yml. Existing GUI files are preserved; previous nested GUI files are copied into the new location only when it is absent. Compare customized files with the shipped defaults to adopt changed layouts. No new .runtime.lock is created: lifecycle ownership uses an unused byte range of the persistent installation-ID file, without changing that ID on reload.

For the new storage.yml use mode: single for SQLite, or mode: multi with the MySQL values under multi. Existing config.yml storage settings continue to win until explicitly migrated; this avoids silently switching a live database. Preserve Punishments compatibility prefixes when sharing existing EMP tables.

StrawBaltop, StrawHide, StrawFastCrystal and StrawMobSpawns are new independent products. They require their own matching panel product/key. Packet features require a compatible ProtocolLib build; overhead Hide nametags use TAB. No live protocol certification is implied. All versions remain 1.0.0.

Homes exposes five home positions on the main screen and fourteen on More Homes, with numeric permission limits capped at 19. Existing saved homes are not deleted. /checkhomes <player> uses strawio.homes.others.view.

Settings actions are in config.yml. TAB supplies the scoreboard action; optional Straw owner services supply their toggles. External-only features display unavailable until an owner command is configured, rather than saving a cosmetic toggle with no effect. Configured commands run as the player and keep their own external state.