handlers: unit operations — fusion, evolution, selling, and favourites - #34
Open
Seltraeh wants to merge 4 commits into
Open
handlers: unit operations — fusion, evolution, selling, and favourites#34Seltraeh wants to merge 4 commits into
Seltraeh wants to merge 4 commits into
Conversation
Implements the four unit management operations. UnitMix fuses fodder units for XP with the Great and Super success multipliers, debits zel and returns the full reinforcement and team payload. UnitEvo evolves a unit, preserving IMP stats and emitting all five response fields including the original MST id, without which the client crashes during the evolution animation. UnitSell deletes rows and credits zel. UnitFavorite persists the lock flag, and UserInfo reports it back so locks survive a reload. All three destructive handlers call returnEquippedSpheres() before their DELETE. Equipped spheres are owned items; deleting the unit row without returning them first destroys them with no feedback to the player.
split/03-schema-foundation collapses the duplicate stat columns in user_units onto one column per concept -- unit_lvl / base_rec / ext_rec, with add_heal and limit_over_heal renamed to add_rec / limit_over_rec. UnitEvo and UnitMix read and write those columns, so they move with it or break on rebase. Only the SQL text and row["col"] lookups change. The packet field names are the client's own vocabulary (FriendInfo and ReinforcementInfo genuinely say base_heal where UserUnitInfo says base_rec, both carried from IDA), so lines like rd.base_heal = br["base_rec"] are correct: packet field left, column right. See the split/03 commit for the full reasoning.
split/03-schema-foundation stops persisting fe_bp and fe_max_usable_bp: they were stored as the literal constants 100 and 200 and never computed from or consumed by anything, with Frontier Evolution unimplemented. UnitEvo and UnitMix only ever selected those columns to copy them straight back into the response packet, so the reads go with the columns or the SELECTs break. The packet fields themselves are untouched -- the client still receives both keys, now defaulting to 0. Only the round trip through the database is gone.
split/03-schema-foundation drops user_units.leader_skill_id as species data. UnitEvo already used targetMst->leader_skill_id; UnitMix was the only reader of the stored copy and now takes it from baseMstData, which it already held for element/exp_pattern/max_lv. The packet field is untouched -- the client still receives the key.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
handlers: unit operations — fusion, evolution, selling, and favourites
Branch:
split/05-unitsBase:
devMerge position: 05 of 13
Largest PR in the series at ~790 lines, but it's four independent handlers sharing one helper.
What's included
UnitMixMw08CIg2UnitEvo0gUSE84eUnitSellRi3uTq9bUnitFavorite2p9LHCNhUnitEvoemits all five response fields including the original MST id. Omitting it crashes the client during the evolution animation.The important bit
All three destructive handlers call
returnEquippedSpheres()before their DELETE. Equipped spheres are owned items; deleting the unit row without returning them first destroys them silently with no player feedback. This is why the PR is sequenced after Items — the helper writes touser_items.Splitting further
If ~790 lines is too much in one pass, this divides cleanly into
UnitMix+UnitEvo(~600) andUnitSell+UnitFavorite(~190). They share nothing beyond the helper. Happy to split on request.Verification
Fuse, evolve and sell a unit with spheres equipped; confirm the spheres reappear in the warehouse each time.