Follow-up to #2729.
## Problem
At load, `ReadAnchoredTime` shifted **every** anchored value forward by the downtime, including values that were already in the past when the save started. That caused two problems.
**An expired deadline came back.** A deadline that passed 5 minutes before a 30-minute outage loaded 25 minutes in the future. For example:
- `Sheep.NextWoolTime`: a sheep that was ready to shear stopped being ready.
- `PlayerVendor.NextPayTime`: an overdue payment was pushed back.
- `BaseCreature.SummonEnd`, the spell fields' `End`, `TransientItem.Expiration`, and the ChampionSpawn times could move the same way.
**Records were rewritten for nothing.** The first save after every restart rewrote:
- stamps of things that had already happened: VirtueContext's `LastHonorUse`, `LastSacrificeGain`, the four `Last*Loss` stamps, and `Corpse.TimeOfDeath`
- every deadline that had expired long ago.
## Change
- **`IGenericReader.AnchoredTimeOrigin`** is the loaded save's start time.
- `GenericEntityPersistence` and `GenericPersistence` set it from `World.LoadedSaveStartTime`.
- `BufferReader`, `UnmanagedDataReader` and `BinaryFileReader` expose it.
- **`ReadAnchoredTime` returns any value at or before the origin exactly as saved.**
- A deadline still running at save start is shifted as before and keeps its remaining time.
- Readers without an origin keep the old behaviour.
- **This covers every anchored field, including generated ones.** Generated `[AnchoredDateTime]` fields call `reader.ReadAnchoredTime()`, so the one change covers all 26 generated fields as well as the manual reads. `[DeserializeTimer]` only restores timers that were running at save time, so it is unaffected.
- **The `[AnchoredDateTime]` section of `dev-docs/serialization.md` and the `WriteAnchoredTime` doc comment describe the new rule.**
## Behaviour change
Downtime now counts toward windows measured from a past stamp:
| Window | Length |
|---|---|
| Honor use | 5 minutes |
| Sacrifice gain | 1 day |
| Virtue atrophy | 7 days |
| Instanced corpse looting | 3 minutes |
A 30-minute outage makes a 7-day atrophy fire about 0.3% sooner. No format change.
## Tests
New tests in `AnchoredTimeTests`:
- A deadline running at save start keeps its remaining time.
- A deadline that passed before save start stays passed.
- A past stamp is not shifted.
- A value exactly at save start is not shifted.
`Server.Tests`: 845 passed. `UOContent.Tests`: 1140 passed.
ReadAnchoredTime shifted Item.LastMoved, Item.DecayResetTime and
Mobile.LastStr/Int/DexGain forward by the downtime at load. The bytes
were stable from save to save, but the first save after every restart
rewrote one timestamp in nearly every item record and most mobile
records, which defeats any per-record backup or delta save.
- LastMoved and DecayResetTime are read as saved. The downtime credit
is applied after load by Item.CreditDowntimeToDecay, which moves
DecayResetTime only for items whose decay countdown was still running
when the save started. Every other item keeps its bytes, and decay
timing is unchanged.
- World.LoadedSaveStartTime exposes the loaded save's anchor so the
credit can tell which countdowns were running.
- Stat-gain stamps are read raw. The cooldown is minutes long, so
downtime counting toward it costs nothing.
No format change: these fields were already absolute ticks.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Moving Shot charged its mana in `OnBeforeSwing`, before `BaseRanged.OnSwing` decided whether to fire. A swing that fired nothing (a paralyzed or frozen archer, no ammo, a failed harmful check) still took the mana and left the move armed. Every swing after that charged again, so inside the 3-second window you paid twice, until the archer ran out of mana.
`OnBeforeSwing` now only checks the mana. Moving Shot's own `OnHit`/`OnMiss` charge it, and those only run once a shot has fired. This is how the other weapon abilities pay. A miss still costs mana. A parried shot no longer does: the parry clears the move before `OnHit` runs, the same as for every other ability.
