diff --git a/projects/DenarEconomy/ledger.md b/projects/DenarEconomy/ledger.md index 5517260..21ffe5a 100644 --- a/projects/DenarEconomy/ledger.md +++ b/projects/DenarEconomy/ledger.md @@ -96,4 +96,23 @@ Choose operation IDs so that a retry reuses the same ID. Derive the ID from the **Events.** `PlayerEarnMoneyEvent` fires after a taxable earning or trade has applied, with the earner's account name, the gross amount and `getCharacter()`. It can fire again when an operation is retried, and changing its amount no longer affects tax. `PlayerBankPulseEvent` fires before `/deco deposit` and `/deco withdraw`, and `PlayerDepositMaterialsEvent` fires on a main-hand right click with an item; both carry `getCharacter()` and fire only for a player with a current character. -**Older calls.** `OfflineModifier.apply/change/balance`, `MoneyManager.addMoney/addMoneyToAccount/changeBal/doTaxes/getBalance`, `PlayerManager.get` and the per-player `Database` methods still compile. They act only on an online player's current character: changes post from the mint with reason `api` and never overdraw, and `doTaxes` returns the policy's tax. Amounts that are not finite or do not fit in whole cents are refused before any posting. For an offline player or one without a character they refuse (false, zero or nothing) and log the first caller of each method with a stack trace. `PlayerManager.get` returns read-only balances whose `Account` mutators throw `UnsupportedOperationException`. Move callers to `Denars`; these methods are kept for one release. +**Removed account APIs.** Account-addressed balance and mutation calls are removed: + +| Removed calls | Replacement | +| --- | --- | +| `OfflineModifier.apply/change/balance`; `MoneyManager.changeBal` | `Denars.post/transfer/balance` with explicit character accounts | +| `MoneyManager.addMoney/addMoneyToAccount/doTaxes/getBalance` | `Denars.earn/taxFor/balance` with a captured `CharacterRef` | +| `PlayerManager.get`; `DenarEconomy.getPlayerManager()` | `Denars.active/balance` | +| `Database.savePlayerData/loadPlayerData/getPlayerBalance`; `LegacyCalls` | The `Denars` API above | + +Capture the character or session when an action begins. A deferred callback must +keep that identity; resolving the account's active character again can pay a +different character after a switch. Store the operation ID before effects and +reuse it on retries. + +`OfflineModifier.load/playerId/remember` still provide account name lookup. +`Database.hasPlayerData(UUID)` still checks whether the player is online with an +active character, and ledger totals and rankings remain available. The legacy +`PlayerData`/`Account` file readers, imported archives, reviewed heirs and ledger +operation history remain required for migration and recovery. Removing an API +does not authorize deleting that data. diff --git a/projects/SimpleFactions/docs/vehicle-owners.md b/projects/SimpleFactions/docs/vehicle-owners.md index 7ccfb36..09a7bac 100644 --- a/projects/SimpleFactions/docs/vehicle-owners.md +++ b/projects/SimpleFactions/docs/vehicle-owners.md @@ -35,6 +35,14 @@ enables, factions run without vehicles and the log says so once. If it is older non-staff, faction stamps are not written, and upkeep is still charged from the personal registry rows. +The fallback claim guard selects the modern `VehicleOwnershipChangeEvent` when +available and blocks non-staff `CLAIM` actions. Older VehicleFramework versions +use a separate legacy-event bridge, loaded only after its class probe succeeds. +This lets the same SimpleFactions build run with VehicleFramework before and +after removal of `VehicleOwnerClaimedEvent`. Other ownership reasons keep their +existing checks. Upgrade SimpleFactions first if the two plugins are installed +across separate restarts; a coordinated stopped installation is preferred. + ## Owner migration The first start in characters mode records a plan before it changes anything. diff --git a/projects/VehicleFramework/docs/ownership.md b/projects/VehicleFramework/docs/ownership.md index 1d2f1f7..70c0544 100644 --- a/projects/VehicleFramework/docs/ownership.md +++ b/projects/VehicleFramework/docs/ownership.md @@ -82,9 +82,19 @@ Events: | --- | --- | | `VehicleOwnershipEditCheckEvent` | Before an ownership-menu button is shown and again on every click. A pure check: `deny()` hides or refuses the control. An empty reason means opening the menu. | | `VehicleOwnershipChangeEvent` | Before a player's change is written. Cancellable. Carries the vehicle actually changed (the locomotive for tickets), the reason (`CLAIM`, `CLEAR`, `TAKEOVER`, `WHITELIST_ADD`, `WHITELIST_REMOVE`, `WHITELIST_TOGGLE`, `TICKETS_TOGGLE`), an operation ID, the acting character, a staff flag, and the target character or raw whitelist entry. | -| `VehicleOwnerClaimedEvent` | After the change event, for claims only. Still cancellable; kept for older listeners. | | `VehicleOwnershipChangedEvent` | After the write, with the same operation ID, the outcome and the values before and after. For a player change it always fires once the change event has fired, including when the change was cancelled or the save failed. For `setOwnership` it fires only on `OK`. | +`VehicleOwnerClaimedEvent` is removed. A listener that vetoes a claim must handle +`VehicleOwnershipChangeEvent` with reason `CLAIM`; the matching post-event still +reports `success == false` when the claim is cancelled, under the same operation +ID. Install the SimpleFactions release with the modern claim guard before +upgrading VehicleFramework: older SimpleFactions releases name the removed event. + +Standalone `names` mode remains supported. Legacy `player_` values and held +ownership records remain readable; removing the event does not release or delete +them. The TFMC integration requires `characters` mode and a ready SimpleFactions +ownership authority. + Services, looked up on every call: - `VehicleOwnershipAuthority`: SimpleFactions registers it once it handles the change events. `ready()` returning false counts as missing.