2.6 KiB
Purpur Carry
Purpur Carry is a Purpur 26.3 plugin for native animal and Villager carrying on SoMC. The approved behavior is specified in the SoMC OKF wiki.
Requirements
- Purpur 26.3 build 2651
- Java 25 or newer
- Node.js 20 or newer for release-tool verification
Build
./gradlew clean check jar
The command compiles with fatal warnings, runs Java domain/adapter/distribution tests, the checksum-pinned Purpur event/command suite, and TypeScript release-tool tests, then writes build/libs/purpur-carry-<version>.jar. Purpur is compile-only and is not bundled. The pinned runtime is extracted in patch-only mode; tests do not start a server, open a port, create a world, or accept the EULA.
Carrying
Players with the default-true purpurcarry.use permission can hold an ordinary Lead and sneak-right-click one eligible live non-hostile animal or Villager. Owned tameables accept only their owner; hostile mobs, bosses, Wandering Traders, leashed entities, existing vehicles/passengers, and unavailable participants are rejected without replacing their native interaction.
A successful action uses the same live entity as the player's one native passenger. The Lead is reusable and unchanged. Right-clicking air or a block with a main-hand Lead requests native release. Native placement, motion, falling, damage, suffocation, and environmental hazards remain authoritative; Carry does not serialize, clone, rescue-teleport, eject, grant invulnerability, or rewrite entity state.
Disconnects, deaths/removals, accepted teleports/portal transitions, carrier vehicle entry, native dismounts, and plugin disable reconcile only the owned relationship. Native cancellation is respected, and refused dismounts are reported instead of forced. /carry and /carry help explain the controls and hazards; completion suggests only help to permitted senders.
Releases
Gitea Actions verifies the exact public source revision. Pull requests validate conventional commits; main-branch conventional commits drive semantic releases. Publication uses the repository-scoped RELEASE_TOKEN only through an in-memory Git credential helper and authenticated request headers inside the release process, never command arguments. A release is published only after the exact versioned JAR has passed the complete verification suite and uploaded successfully through a draft transaction.
A source release is not installation or deployment approval. GitOps preparation and production release use the separately gated workspace runbooks.