TrackingData.java
The tracker framework (tracking.tracker — TrackerDefinition, TrackerRegistry, TrackerManager) is currently routed through MarieAPI.java / TrackerRegistrationDelegate in api.marieapi.
This was built before the "massive subsystems get their own folder + facade" rule existed, so it's now inconsistent with that rule (same category as the color system, which does have its own folder + MarieColors facade).
Not touching tonight. Open question for later: leave it as-is, or migrate it to its own facade (e.g. MarieTracking) to match — possibly bundled with the calorie-tracker-sync work already queued (per-tracker delta sync, MarieAPI.getCurrentTrackerValue client-side footgun).
open that sync-ownership conversation now yeah this
Reconciled existing architecture with real-time sync requirements
Reconciled existing architecture with real-time sync requirements
Before designing anything — there's already a generic sync mechanism in MarieLib I didn't know about until just now: marie-resources module, MarieResourcesAPI. Worth understanding exactly what it does and doesn't cover, because it changes the shape of this conversation.
What it actually does: a mod registers a Supplier<CompoundTag> (server-side, "here's my current snapshot") and a Consumer<CompoundTag> (client-side, "here's how I apply it"), keyed by a registryId string. MarieLib sends that snapshot to every player on login, and again to everyone whenever the mod calls broadcastConfigSyncReload after something changes server-side. It's what replaced Nourished's hand-rolled SyncNourishedConfigSnapshot for config values.
Why it doesn't solve the tracker problem as-is: it's built for global, infrequently-changing, manually-triggered state — config values, registry contents. Two mismatches with what tracker accumulators need:
- Broadcast vs per-player.
broadcastConfigSyncReloadsends the same snapshot to every connected player. A tracker accumulator is inherently per-player data — Player A's calorie count has nothing to do with what Player B needs synced. - Manual/on-reload vs continuous. This mechanism fires on login and whenever the mod explicitly calls reload. It has no concept of "resync automatically every time the underlying value changes," which is exactly what a tracker needs — it changes on every
incrementTrackercall, not on a discrete "config was reloaded" event. That's precisely why Nourished ended up hand-buildingSyncDietDeltaPayloadin the first place: this generic mechanism genuinely wasn't the right shape for it.
So the real question isn't "should MarieLib reuse marie-resources" — it's whether a second, complementary sync mechanism is worth building: per-player, triggered by tracker mutation rather than manual reload, scoped to "just this player's tracker state" rather than a global broadcast. That's a different enough shape that I don't think it's a small extension of marie-resources — it's closer to a new sibling capability.
Before I sketch anything: is the actual want here "every tracker MarieLib manages gets synced automatically, no mod has to think about it" (full ownership, similar ambition to what pushed calories into the tracker framework in the first place), or something narrower — like "give mods a per-player delta-sync helper they still have to wire up themselves, just so they're not hand-building a payload class each time"? Those land at pretty different scopes.