|
1 | | -# Scheduled channel actions |
| 1 | +# Bread and scheduled channel actions |
2 | 2 |
|
3 | | -Channel-wide purchases that create a future event are durable game facts rather |
4 | | -than in-process timers. Each scheduled action carries a monotonic identifier, |
5 | | -the catalog item, its source player, creation time and exact due time. |
| 3 | +Live bread follows the reference method-2 behaviour. Each item-21 purchase |
| 4 | +costs 4 XP, grants +2 temporary karma and creates an independent one-hour effect. |
| 5 | +Owner bread uses the same channel effect without charging a player. A maximum |
| 6 | +of 20 active pieces is accepted for new player and Owner requests; refusals do |
| 7 | +not spend XP. Existing historical surplus is retained until expiry, with the |
| 8 | +attraction count capped at 20. |
6 | 9 |
|
7 | | -The duck call accepts an injected deadline strictly after purchase and no later |
8 | | -than ten minutes afterward. The mechanical duck always uses an exact ten-minute |
9 | | -delay. The caller resolves the variable call delay before settlement, and the |
10 | | -journal records that concrete deadline so recovery never samples it again. |
| 10 | +Bread remains in place across every successful flight during that hour. At each |
| 11 | +new takeoff, the engine adds 20 seconds per active piece to the flight's normal |
| 12 | +lifetime, including called, mechanical and Owner flights. Adding or expiring |
| 13 | +bread does not change the expiry of a duck already in flight. No piece is eaten |
| 14 | +or removed by takeoff and no false consumption announcement is emitted. |
11 | 15 |
|
12 | | -Advancing the game clock removes every due action and emits one |
13 | | -`channel_action_due` outcome. Simultaneous actions are ordered by due time and |
14 | | -then identifier. A later runtime dispatcher will translate those outcomes into |
15 | | -real or mechanical flights; no timer, socket or channel operation exists in the |
16 | | -game engine. |
| 16 | +The scheduler's fixed base is 24 slots per UTC day. Adding bread or expiring a |
| 17 | +piece redraws a whole-day plan of 24 + active pieces. Hours are selected without |
| 18 | +replacement, resetting the hour pool when exhausted; minutes are unique within |
| 19 | +the resulting day. The nearest existing future time is retained on addition, |
| 20 | +and also on expiry while at least one piece remains. When the last piece |
| 21 | +expires the plan is redrawn with 24 slots. This is attraction, not a guarantee |
| 22 | +of an additional duck during the hour. Past times in the newly drawn plan are |
| 23 | +not fired retroactively. Existing UTC boundaries and Europe/Paris display are |
| 24 | +preserved; the underlying reference scheduling method is used without changing |
| 25 | +the bot's operating timezone or configured base quota. |
17 | 26 |
|
18 | | -The duck detector is a player-scoped one-use effect. A successfully started |
19 | | -flight consumes every waiting detector and emits a private-alert outcome. A |
20 | | -rejected start while another flight is active consumes nothing. IRC NOTICE |
21 | | -routing is performed once per detector owner by the runtime scheduling adapter. |
| 27 | +Expiry participates in the runtime wake-up even without chat activity. Bread |
| 28 | +fingerprints and concrete plan draws are journaled; reconnecting or restarting |
| 29 | +with unchanged bread does not redraw the schedule. Paid duck calls and mechanical |
| 30 | +actions remain queued across bread expiry/replanning, including while another |
| 31 | +flight blocks them. A successful matching start completes only one due action. |
22 | 32 |
|
23 | | -Channel bread is also tied to a successful start: one active stack is consumed, |
24 | | -oldest activation and then lowest identifier first. Other active stacks remain |
25 | | -available until a later flight or their independent one-hour deadline. Rejected |
26 | | -starts consume no bread. |
| 33 | +The detector retains its one-shot private alert contract. All precise planning, |
| 34 | +expiry and delay diagnostics go to the Owner NOTICE, partyline or application |
| 35 | +log. Player confirmations contain durations and effects, not takeoff times. |
| 36 | + |
| 37 | +The first live scheduler step writes an explicit `enable_hourly_bread` event. |
| 38 | +Before that event, old purchases and flights replay their original one-hour / |
| 39 | +one-consumption semantics. Existing flight deadlines and old player scores are |
| 40 | +not recalculated. New `replan_bread_schedule` events contain the chosen deadlines. |
| 41 | +Schema 22 carries the optional bread plan fingerprint; schema-21 checkpoints |
| 42 | +remain authoritative and byte-identical old event payloads remain valid. |
0 commit comments