[blevouschurverantunt]

Summary

Adds an opt-in sync type store_offers that emits store_offer events: the Faction Store's consumable offers (the favor levels) with their prices and rank gates. It is off by default and only emitted for targets that enable it. Refs #301 (faction-store half only; refinery conversions are not covered).

What changes

• store_offers under [sync] and per target (one SyncOptions row, config.cc untouched). English example only.
• Store offers arrive in Platform-service responses, which already reach the ProcessResultInternal detour (both registries share one compiled method, seen on Windows). The detour checks sync_options.store_offers first and only then recognises a Platform ServiceResponse and hands it to a small handler. With the option off, behaviour is exactly as before. No new hook, no new server calls.
• One store_offer event holds the whole factions snapshot of consumable offers (about 120 favor levels plus a couple of other items), sorted by bid then cid, and is queued only when its hash changes:

  {"type":"store_offer","category":"factions","offers":[{"bid":1879677865,"cid":4257393301,"cost":[{"rid":1622589916,"amount":1390}],"req":[{"type":"faction_standing","id":4138978039,"amount":4}],"valid_count":2,"same_remaining_count":2}]}

• cost and req are arrays of small objects, like officer_traits. A snapshot replaces the previous one so a bought level drops out; per-offer events would need removal events for that.
• Digit.PrimePlatform.Content.proto: Resource.amount is now fixed32. The server sends it as fixed32 (0d e8 03 00 00 = field 1, wire type 5, value 1000; check with protoc --decode_raw), but the proto said uint32, so the generated parser dropped it into unknown fields. Nothing else in the mod uses this message.

Notes

• req[].amount for faction_standing is a zero-based tier index. valid_count / same_remaining_count are the raw OfferDetails.validCount / sameRemainingCount, not the in-game "Available" number.
• Platform EntityGroup types use a different enum than PrimeServer (type 0 is STATICTRANSLATIONS there but UserProfiles here), so with the option on these responses skip HandleEntityGroup. With it off they go through it exactly as before. Skipping them unconditionally would also stop that existing misread, but I kept this change scoped to the option.
• Ids are numbers (a string if non-numeric). About 120 offers, ~25 KB per snapshot.
• Touches the same SyncOptions/example-config lines as Sync: opt-in live fleet state (fleets) #325 and Add in-game Mod Settings with persistent preferences and shortcut editing #333; I'll rebase whichever lands second.

Verified

Windows, client build 272, against a live sync target:

• 122 offers about 30 s after login, without opening the store.
• Buying one favor level replaced the snapshot 1.6 s later with that offer gone. Opening the store alone usually sent nothing (unchanged hash).
• This revision, live: the 122-offer snapshot (new field names) arrived about 55 s after login; three cached real responses decoded offline with the fixed proto give 122 offers, 117 priced and 5 unpriced (empty cost), and an identical replay queues 0. The earlier revision (hand-decoded fixed32) showed the same behaviour. macOS not tested.

Checks

Fork CI not run (Actions unavailable on my account this month). Local MSVC release build clean; git diff --check and clang-format clean on changed lines. Example-config validator not run locally. No tests, CHANGELOG, version or other-locale changes.

🤖 Generated with Claude Code