Skip to content

Calendar V5: generated weather the Director can paint over by hand #765

Closed
2 of 2 issues completed
Closed

Description

@keyxmakerx

Why this issue exists: generated weather was promised twice, then dropped without anyone deciding to drop it.

  • 2026-07-23 brief: "per-zone auto-generated weather with forecast + history (the W2 engine, finally)".
  • The operator's own brief, 2026-08-15: "Two modes: dynamic (generated) and manual. Automatic output must still be manually editable. Manual editing is CLICK AND DRAG — paint weather across a range of days. In editing mode the cells strip down to dates only."
  • The V5 design brief (2026-08-21) kept "one reading per day" and the players' reveal model, but never mentioned generation again.

What it is:

  • Generate. The Director picks a climate for the calendar, or for a zone. Chronicle fills in each day's weather from the season, with gentle day-to-day continuity so a storm doesn't flip to clear sky at random. They can regenerate any range of days.
  • Paint. Click and drag across days to set the weather by hand. In this editing mode the day cells strip down to dates only.
  • Rules already set: one reading per day. Past days and today show to everyone; future days show only to the Director, ghosted.

Reference: Calendaria's weather system, which the operator pasted in on 2026-06-12: climate zones, per-season weights, inertia and forecasts (Cordinator references/calendaria-wiki/Weather-System.md). Match what Foundry syncs so the two never disagree.

Code today: internal/plugins/calendar/model.go defines Weather, Wind, Precipitation and WeatherZone, but nothing generates or serves them. The sync API's weather routes still answer 503.

When: after V5's core (the month grid, events and the day card) has shipped.

Activity

  1. keyxmakerx commented on Sep 27, 2026

    @keyxmakerx
    OwnerAuthor

    Signed on 27 September: owner editing, mockup version 2. This covers choosing many days, setting any weather including magic, and generating from one sheet. The build must match that mockup. What it settles:

    • Any day can have any weather. A date's card offers the six common kinds first. "More weather…" opens every kind, grouped as Common, Stormy, Nature and Magic, plus the owner's own, with a search box. Weather set by hand is never replaced by a generator.
    • New kinds in place. An event's kind list ends in "New kind…": a name, an icon and a colour, shared by every calendar in the campaign.
    • Edit mode: choose many days by click, drag, a whole week or a weekday. A bar then offers:
      • paint weather;
      • generate;
      • move the days' events;
      • clear;
      • hide from or reveal to players;
      • lock.
    • Generate opens one sheet for weather, sky events, moon nights, events and the owner's own tables. Results preview as faint marks; the owner keeps some, rerolls the rest, then applies, with Undo.
    • Settings (the gear): saved recipes, the owner's own weather and kinds of event (with a year's preview), and tables of things that can happen.
    • Who can use Edit and the generators (the operator's answer): the owner and their co-Directors.
    • Players never see any of this, and still see days only up to today, under the rule recorded on Calendar V5: requirements and lessons carried over from the v4 calendar #741.

    The decisions recorded on the card stand:

    • Events a generator makes for later days reach players on their day. Festivals and yearly events are shown ahead, the same as events added by hand.
    • The table-schedule calendar still shows players their upcoming sessions.
    • Turning a kind of event into a table replaces it, so nothing is made twice.

    Generated by Claude Code

  2. keyxmakerx commented on Oct 2, 2026

    @keyxmakerx
    OwnerAuthor

    Findings for whoever builds this (checked against main, not started):

    What exists today:

    • Storage: V5's schema keeps only one current-weather row per calendar (calendar_weather, migration 020). The old per-day table (calendar_day_weather, migration 008) was dropped by 019 and not recreated, so weather per day needs a new table: an append-only, idempotent migration through the migration-safety check.
    • The generator already exists: static/js/widgets/chronicle_gen.js has weather generation, forecasts, climates and Calendaria's 42 presets. Today only the wizard's Generate step loads it.
    • The edit bar (calendar_editor.js) offers only Hide, Reveal and Shift events. The signed mockup's Paint weather, Generate and Lock were left out because there is no per-day weather write endpoint.

    Suggested slices, one PR each:

    1. Storage, API and the player rule: past days and today show to everyone, and future days show only to the Director. Forecasts stay off unless forecasts_enabled is on. The day's reading shows on its day card.
    2. Paint weather in edit mode, with the signed picker: six common kinds first, then "More weather…" grouped as Common, Stormy, Nature and Magic, with search.
    3. The Generate sheet: results preview as faint marks, the owner keeps some and rerolls the rest, then applies, with Undo. It never replaces weather set by hand.

    The owner's own weather kinds come after these.


    Generated by Claude Code

  3. keyxmakerx commented on Oct 2, 2026

    @keyxmakerx
    OwnerAuthor

    Slice 1 (storage and API) merged in #871.

    Done: calendar_weather_days (migration 021), GET/PUT .../calendars/:calid/weather/days and POST .../weather/days/clear. Players only ever see days up to today. A generated write never replaces a painted day.

    Next:

    • The day card and month-grid weather mark. The mockup card "Weather per day: how a day's weather looks" is on Sign-offs and waits on approval.
    • Then Paint weather in edit mode, then the Generate sheet.

    Still open, not built:

    • forecasts_enabled does not open future days to players yet (TODO(#765) in ListDayWeather).
    • Day readings are not in the campaign export.
    • The sky pane will read the shown day's reading once the Animated sky pane thread adds the hook.

    Gotcha: for real-time calendars, the service uses the stored current date. I found no code that overlays the wall clock, even though the TracksRealTime comment says one exists.


    Generated by Claude Code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions