Conversation
Since the 3.29 data, ParseRaw adds a talisman's base enchant when the item text has none. Greatwolf and Black Maw Talismans saved before 2.66 have no enchant line, so ItemsTab:Load counted a line that the saved ModRange ids never included, and each line got the roll of the next one (Eyes of the Greatwolf: 20% physical damage reduction instead of 24%). Skip the enchant lines added from the base when numbering the saved ids.
Since the 3.29 data, the Black Maw Talisman base carries "Has 1 Socket" as an enchant, and ParseRaw adds a base enchant when the item text has none. Items that carry the same line as an implicit (talismans saved before 2.66, the Night's Hold unique text, legacy items pasted from the game) got it twice: the item had two sockets, and the warning for too many gems in its slot no longer fired. Skip a base enchant line whose text is already an active implicit.
Before 2.66, PoB could not parse the in-game "value(min-max)" format and saved a pasted line such as "14(9-21)% increased maximum Life, Mana and Global Energy Shield" as is, with the default range in its ModRange. ParseRaw now reads the roll from that value, but ItemsTab:Load then applied the saved ModRange over it, so the line loaded as 15% instead of 14%, and saving the build kept the wrong value. Lines whose range comes from their written value keep it on load. # Conflicts: # src/Classes/ItemsTab.lua
PoB 2.66 and older saved in-game property lines such as "Intangibility: 5%"
and "Memory Strands: 58", and flask lines such as "Lasts 4.00 Seconds", as
mod lines with a ModRange entry each. 2.67 reads them as item properties or
skips them, so ItemsTab:Load applied every later ModRange one line too early:
an Entropy Grip saved in 2.66 loaded its "+(10-13) to all Attributes" roll at
0.5 instead of 1.
Save writes at most one ModRange per mod line, so more entries than lines
means the saved positions no longer match. The entries are then ignored and
the {range:} tags of the item text are kept.
The line count leaves out talisman enchants added from the base data, as the
ModRange id loop already does; both now use countSavedModLines.
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.
Description of the problem being solved:
Builds saved with 2.66 or earlier load some items with wrong values in 2.67. Four separate causes, one commit each. They complement #10374, which fixes the stat-order sort and stays separate.
ModRangeentries did not count that line, so each one lands one line early: in the first build below, Eyes of the Greatwolf shows 24% additional Physical Damage Reduction instead of 28%. Enchant lines added from the base data are now left out when the saved ids are matched.14(9-21)%as is, with a defaultModRangeof 0.5. 2.66 reads the roll from the written value, thenItemsTab:Loadoverwrites it with that default: Crown of the Inward Eye in the second build (the copy with 18% quality) loads 15% instead of 14%. A roll read from the written value is now kept.ModRange. 2.67 no longer reads them as mod lines, so later rolls shift by one: the unequipped Entropy Grip in the third build loads its "+(10-13) to all Attributes" craft at the middle of its range instead of the top, and shows +14 instead of +15 with its 20% quality.Savewrites at most oneModRangeper mod line, so when an item has more entries than lines they are ignored and the{range:}tags of the item text are kept.Builds already saved again with an affected version keep the wrong values; these changes cannot restore them.
Steps taken to verify a working solution:
Link to a build that showcases this PR:
Before screenshot:
After screenshot: