Skip to content

handlers: report inventory, unit, town and campaign state from UserInfo - #40

Open
Seltraeh wants to merge 1 commit into
decompfrontier:devfrom
Seltraeh:split/11-userinfo-state
Open

handlers: report inventory, unit, town and campaign state from UserInfo#40
Seltraeh wants to merge 1 commit into
decompfrontier:devfrom
Seltraeh:split/11-userinfo-state

Conversation

@Seltraeh

@Seltraeh Seltraeh commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

handlers: report inventory, unit, town and campaign state from UserInfo

Branch: split/11-userinfo-state
Base: dev
Merge position: 11 of 13

Part of the PR #28 split. Each PR branches from dev and contains only its
own changes, so this diff is exactly one subsystem. The set is designed to be
merged in numeric order; merging all 13 reproduces PR #28 byte for byte
(verified against tree 79a4e065).

Later PRs in the series touch Handlers.hpp, GmeControllerHandlers.cpp and
UserInfo.cpp too, so once earlier ones land this branch may need a rebase.
Those conflicts are always additions on both sides — keep both. Maintainer
edits are enabled, so feel free to push the rebase directly to this branch.

Collects every UserInfo response change into a single PR, so only one pull request in the series touches this file.

What's included

Each block reads a table created in PR 03 and returns an empty array when that table is empty, so this is additive and inert on a fresh account.

  • Owned items populate warehouse_info, equip_info, item_dictionary_info and item_favorite from user_items, replacing the hardcoded potion and its TODO. Zero-quantity stacks are filtered off the wire but still feed the dictionary, so a species stays in the encyclopedia once seen.
  • Cleared-mission history (UT1SVg59) from user_campaign_missions. This is the progression driver: the client evaluates feature unlocks against this list, so anything gated on "mission N cleared" stays locked without it.
  • Favourited units (3kcmQy7B) so UnitFavorite locks survive a reload.
  • Town state — the three arrays travel together. Every entry in town_location_info needs a matching town_location_detail entry, because the client dereferences the detail for each location and an empty detail array crashes the town scene loader.

Why it's separate

Items, Units, Town and Campaign each needed their own block here. Spread across four PRs they collide on every merge; collected into one they don't. The functional cost is that PRs 04-06 and 10 persist state they don't yet report — merge this and it all lights up at once.

Verification

Fresh account: every array empty, no client complaint. After the tutorial: potion in warehouse. After a town upgrade and a cleared mission: both survive a relaunch.

Expands the UserInfo response to report the state the preceding handlers
persist. Every block reads from a table created in the schema PR, so this is
additive and returns empty arrays on a fresh account.

Owned items populate warehouse_info, equip_info, item_dictionary_info and
item_favorite from user_items, replacing the hardcoded potion and its TODO.
Zero-quantity stacks are filtered off the wire but still feed the dictionary,
so a species stays in the encyclopedia once seen.

Cleared-mission history (UT1SVg59) comes from user_campaign_missions. This is
the progression driver: the client evaluates feature unlocks against this
list, so anything gated on "mission N cleared" stays locked without it.

Favorited units (3kcmQy7B) are reported back so UnitFavorite locks survive a
reload.

Town state emits the three arrays together. Every entry in town_location_info
requires a matching town_location_detail entry, because the client
dereferences the detail for each location and an empty detail array crashes
the town scene loader.

Collected here rather than spread across the item, unit, town and campaign
PRs so that only one pull request touches this file.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant