Weather from Open-Meteo #47
Labels
No labels
animation
audio
blocked
bug report
controversial
documentation
easy
feature request
hard
medium
multiplayer
physics
ui
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Blocks
#48 Rain and snow
elsie/liuverse
#181 Throw snowballs and build a snowman
elsie/liuverse
#182 Freeze the water and skate it
elsie/liuverse
#189 Make the rain leave puddles and wet reflections
elsie/liuverse
#190 Leave footprints and tire tracks in snow
elsie/liuverse
#220 Bring thunderstorms with lightning and roof rain
elsie/liuverse
Reference
elsie/liuverse#47
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The elevation source was chosen because it needs no account and no
key (
docs/elevation.md), and Open-Meteo is the same deal: free, no key, noregistration. It serves current conditions and a forecast for a lat/lon, which
for a baked campus is one fixed point.
The architectural home is the server, not the bake.
ARCHITECTURE.mdalreadysplits authority with day/night on the server's 20 Hz tick; weather is the same
kind of shared truth -- everyone sees the same sky, it should not be per-client,
and the server is already the thing that owns time. It rides the existing
ServerMsgappend rule.What it buys: rain and snow, a cloud cover that dims the directional light, wind
that leans the trees, and a night that is actually dark in December.
Open question worth deciding early: the client is WASM-capable and connects to a
single compile-time endpoint, so a client with no server would have no weather.
Either the server holds it and offline means "clear", or the weather is baked --
but baked weather from a bake run is nonsense, so this is a real design
decision, not just an HTTP call.
Related