Sync upstream dev (2026-08-27) - #8
Merged
Merged
Conversation
Breach Ring and Refined Breach Ring carry "+20% to Maximum Quality" and "+25% to Maximum Quality" as their implicit, and the Breachlord's prefix grants the same line. Only the "Maximum Quality is #%" wording was handled, so those items showed the implicit as an unsupported modifier. Added alongside it, display only, matching how "Maximum Quality is #%" is treated: PoB does not track quality on rings, so there is no value to apply yet.
…thOfBuildingCommunity#2411) UpdateGlobalGemCountAssignments re-evaluated `provided` for every enabled gem in a socket group, so the last gem examined decided whether the group counted against the skill slot limit. Support gems carry neither fromItem nor fromTree, so adding any support to a group whose active skill is granted by an item or the passive tree flipped that group to counted. This surfaced as a spurious "You have too many gem groups allocated" warning after socketing supports into the default weapon attack (Bow Shot and friends, which carry fromItem = true in Data/Skills/other.lua) or into a skill granted by a unique. Support gems never occupy a skill slot on their own, so skip them when determining whether the group is provided.
…y#2418) The warning for unspent weapon set points was formatted with "Weapon set 2" hardcoded, so a character with fewer points allocated in set 1 was told the spare points belonged to set 2. The count was already correct, as it is the difference between the two sets: a node allocated in both sets is only paid for once, which is why the smaller set is the one with room to grow, and the same reason EstimatePlayerProgress subtracts the minimum of the two from the normal passive count.
…OfBuildingCommunity#2384) * Extract inner functions from new * Replace dynamic inheritance with static copy
…2419) * Count exposure granted to the enemy as an exposure source The Whispering Ice lowers the enemy's elemental resistances through an EnemyModifier, and so does "Enemies in your Presence have Exposure". Neither grants an ExposureChance modifier or the InflictExposure flag, which are the only things hasExposureSource looks for, so the build ends up in a state where the enemy has Fire Exposure while the player is said to be unable to apply it. Condition:CanApply<Element>Exposure gates the "Is the enemy Exposed" config options, so with those items the options are never drawn and the exposure cannot be inspected in the Calcs tab, even though the resistances already reflect it. The enemy's own exposure modifiers are now treated as a source. Exposure still resolves to the largest single source, so enabling the config on top of an item that already grants more does not change the result. * Simplify fix * Remove test --------- Co-authored-by: LocalIdentity <localidentity2@gmail.com>
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
3 participants
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.
Merges 5 upstream commits from
PathOfBuildingCommunity/PathOfBuilding-PoE2@dev:macOS port / fork deltas
No forward-porting needed. Upstream touched
SkillsTab.lua,ModCache.lua,Build.lua,Common.lua,ModParser.luaand added two specs — zero overlap with the fork-only files.Merge was conflict-free.
Verification
git diff --name-only upstream/dev <branch>lists exactly the three fork-only files:src/Launch.lua,src/Classes/TradeQuery.lua,src/Classes/TradeQueryRequests.lua.TradeQuery.luafork delta hash unchanged (bbd0136e) pre- vs post-merge.Launch.luajit.off()block and bothTradeQueryRequests.luafork fixes present.bustednot installed; relying on CIrun_tests/check_modcache.