Release 0.1.1 - #3
Merged
Merged
Conversation
Playtest: died, respawned at the port, was handed the bamboo raft - and every trader refused: "no ship at this quay". The raft was created UNOWNED whenever the player still had an active boat far away, on the reasoning that boarding it is what abandons the old one. But trade transacts against the ACTIVE boat record, so an unowned hull in the pack is not a hold at all; it only became theirs after placing it and getting in. grantRespawnBoat now always uses BoatService.createFor, so the loaner is active and owned the moment it is handed over and the wreck's hull is demoted to an OLD BOAT - still charted, cargo aboard, still theirs to row back out and reclaim. New locale boat.respawn-given-replacing says so. Taking ownership is destructive to whatever they had, so a keepInventory death - where the real boat never left the pack - must not trigger it, or the raft demotes a boat they are holding, cargo and all. stillHasTheirBoat skips the grant there. testBoatWithinReachMeansNoLoaner had been passing for the wrong reason: CommonTestSetup's shared mock Location answers 0.0 to every distanceSquared and world.getName() is unstubbed, so "an ocean away" and "at my feet" were the same test. Stub a world name and a real location. Version 0.1.1 - and deploy.sh no longer hardcodes it, which is what broke the copy. It takes whatever package built and clears stale TradeWinds jars from the addons folder first, since two versions load as two addons. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014as2obVi1QJj8CRTSqXBRr
The house workflow from GushBlock/Border, adapted to this repo. Two differences worth knowing: GIT_BRANCH=origin/main, not origin/master. The pom's release profile activates on the branch we actually release from; point it at master and every build stays a SNAPSHOT and the upload cannot find its file. Tests RUN here. GushBlock skips them because the patched MockBukkit it needs is published nowhere; ours ships inside the repo under libs/, so a bare checkout tests green and the artifact we publish is the artifact we tested. A guard step sits between the two: the jar is named from the pom's build.version and the upload from the release TAG, so a v-prefixed tag or a forgotten version bump used to surface as a bare "file not found". It now says which jar was expected, lists what was built, and names the cause. game-versions lists only 26.2 - the one version TradeWinds is tested on, and what the release notes promise. The compile floor is far lower (clean against paper-api 1.21.10; only the dialog API, Minecraft 1.21.6, breaks below that), so the list can widen as older versions are actually played. MODRINTH_TOKEN and MODRINTH_PROJECT_ID are already set as repo secrets. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014as2obVi1QJj8CRTSqXBRr
Ben: widen the Modrinth game versions. 26.2, 26.1.2, 26.1.1, 26.1 - the same list the other 26.2-era addons publish, so the version strings are known-good at Modrinth's end. The sources compile clean against paper-api 26.1.2 as well as 26.2 (checked, not assumed), so nothing of ours needs 26.2. It stops at 26.1 rather than following our own compile floor down to Minecraft 1.21.6, because that floor was never the binding one: BentoBox 3.18.1, which addon.yml requires, ships Java 25 bytecode (class major 69) like paper-api 26.x, while every 1.21.x paper-api is Java 21 (major 65). A 1.21.x server would have to run a Java 25 JVM before BentoBox could load at all, and BentoBox is built against the 26.x API besides. Our compiler only ever proved TradeWinds touches no 26.x-only Bukkit API. Only 26.2 is playtested; the rest is a compile-level claim, and the comment says so. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014as2obVi1QJj8CRTSqXBRr
Ben uploaded TradeWinds to CurseForge. This is the house publish.yml - the shared BentoBoxWorld/.github reusable workflow, same as BentoBox core, Border and AcidIsland - pinned to master's current HEAD (1f91a0ed, the same SHA those two use; GushBlock's pin is older). It publishes the jar ATTACHED to the GitHub release rather than rebuilding, so a dependency-repo outage cannot block a release that already has a working jar. The 0.1.0 release carries TradeWinds-0.1.0.jar, so that path is proven for this repo. Hangar is left blank (= skipped): HANGAR_API_KEY exists org-wide, but there is no hangar.papermc.io/BentoBoxWorld/TradeWinds project yet. One line to enable when there is. game_versions stays the 26.x family, matching modrinth-publish.yml rather than the longer 1.21.x list the other addons carry - BentoBox 3.18.1 is Java 25 bytecode and cannot load on a 1.21.x server's Java 21 runtime. CURSEFORGE_TOKEN is an ORGANISATION secret, already available here, so nothing more needs adding. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014as2obVi1QJj8CRTSqXBRr
hangar.papermc.io/BentoboxWorld/TradeWinds now exists, so the slug goes in and HANGAR_API_KEY (an organisation secret, already available here) is passed through. Both platforms publish from the same release event. hangar_owner stays at the reusable workflow's default, "BentoBoxWorld". Hangar's API reports the namespace as "BentoboxWorld" - lower-case b - for TradeWinds AND for Border, AcidIsland and bentobox, all of which publish with the default spelling, so the lookup is case-insensitive. The comment says as much, because the casing looks like a typo and is not. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014as2obVi1QJj8CRTSqXBRr
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A single bug fix release: the respawn loaner boat could not be traded from.
The respawn loaner is your boat, not a hull in your pocket. Die, respawn at the port, get handed the harbourmaster's bamboo raft — and every trader refuses you, "no ship at this quay". The raft was created unowned whenever you still had an active boat far away, on the reasoning that boarding it is what abandons the old one. But trade transacts against the active boat record, so an unowned hull in the pack is not a hold at all; it only became yours once you placed it and got in.
The loaner is now active and owned the moment it is handed over, and the wreck's hull is demoted to your OLD BOAT — still charted, cargo aboard, still yours to row back out and reclaim. A new locale line (
boat.respawn-given-replacing) says exactly that.Taking ownership is destructive to whatever you had, so one guard came with it: a keepInventory death leaves the real boat in your pack, and the loaner must not demote a boat you are holding, cargo and all. No raft is lent in that case.
Also here:
CommonTestSetup's shared mockLocationanswers0.0to everydistanceSquaredand its world name was unstubbed, so "my boat is an ocean away" and "my boat is at my feet" were the same test. The respawn tests now use a real location and let distance decide.deploy.shno longer hardcodes the version, which is what broke the copy on the bump. It takes whateverpackagebuilt and clears staleTradeWinds-*.jarfrom the addons folder first, since two versions load as two addons over one world.600 tests green. No hold, boat or ocean model change, so existing worlds and databases carry over untouched.
🤖 Generated with Claude Code
https://claude.ai/code/session_014as2obVi1QJj8CRTSqXBRr