The streamer regen + narya 1.22 dep were mistakenly installed over the
already-published 1.7.1 coordinate (the 2026-07-06 poisoned-vilya incident,
bang-game task #76). New coordinates make the changed artifact distinct from
the clean 1.7.1 on GitHub Packages, matching the nenya 1.7.2-android1 scheme.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017SDW7vBNEjNxk8Qs6wTUYB
vilya's wire-value classes streamed reflectively, which breaks on Android/ART
(nondeterministic Class.getDeclaredFields order): a Stat read on-device pulled
a Place object into Stat._type and desynced the game-object subscription.
Generated explicit declaration-ordered read/writeObject for stats/data (Stat
subclasses + StatModifier pass-through substitution), parlor/data (Table &
co.) and parlor/game/data via bang's genStreamableLibs task — byte-identical
on HotSpot, deterministic on ART.
narya 1.17 -> 1.22 (generated code references com.threerings.io.GenStreamUtil)
+ explicit jsr250 provided dep (@Generated no longer supplied transitively).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HhfHCXYp2ctWi76Z91y9Ut
We can no longer rely on the ability to reflectively access the private members
of java.awt.Rectangle. Modern JVMs are stricter about enforcing cross-module
private access. Prudes.
The GameManager is set up to handle it, so let's not fuss too much about the
fact that we're using a dynamically typed mechanism to send a message from
client to server.
This ensures that our ActionScript artifact is properly published to Maven
Central for all to use.
I'm still putting off creating vilya-tools. Later, later...
I should really split off a vilya-tools from vilya, but I can't be fucked to do
that when I'm already so deep in yak hair that I can't tell whether it's day or
night.
This looks like a bug. Since our bamboo server uses the deploy target for populating the maven
repository, we need to do both libraries there. Alternatively, maybe the build server should use
the install target. (This will overwrite the 1.4.2 jar, but it should be identical).
Tim Claridge
Claridtimo