Second Historic jewel's conquered passives apply or not depending on edit history

Offen
  • Stimmt etwas nicht?
#10,430 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 8 Tagen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
55/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
lua
Bereich
backend, game-dev

Rechercherichtung

Read src/Modules/CalcSetup.lua around the jewel-limit handling, then trace how src/Classes/PassiveSpec.lua uses item.jewelData.limitDisabled when rebuilding tree paths; compare that with the build load order described in the issue. Reproduce with two Limited to: 1 Historic jewels and Ignore Jewel Limits off, then allocate and deallocate an unrelated passive. Done means the second jewel's conquests and resulting totals stay consistent before and after the edit.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

What happens

With two "Limited to: 1 Historic" timeless jewels socketed in allocated sockets and Ignore Jewel Limits unticked, the second jewel's conquered passives (the changed notables and the added small-node stats) are applied or not depending on what you did since the build was opened. The same build gives different numbers.

Steps (derived from the code):

  1. Allocate two jewel sockets and socket a timeless jewel (e.g. two Lethal Pride) in each. Keep Ignore Jewel Limits unticked (the jewel limit warning appears).
  2. Save and reopen the build. Note the stats and look at the passives in the second jewel's radius.
  3. Allocate any unrelated passive, then deallocate it again.

Expected: the same numbers before and after step 3. Either the second jewel's conquests never apply (consistent with the limit) or they always do.
Actual: right after opening, the passives in both jewels' radii are shown and counted as conquered. After the allocate/deallocate (or any other edit that rebuilds the tree paths), the second jewel's passives go back to normal and the totals change. Reopening the build brings the first numbers back.

Cause

The jewel limit is applied in CalcSetup, which sets and clears item.jewelData.limitDisabled on the item as a side effect of each calculation:

The tree code decides which jewels conquer or scan their radius by reading that flag. This applies to both Abyss timeless conquests and the radius scan used for Legion conquests:

On load the tree is built after the items (Build.lua#L654-L677) but before the first calculation, so the flag is still nil on every jewel and both jewels conquer. The first calculation then marks the second jewel limitDisabled, but the tree is not rebuilt. The second jewel's conquests stay until the next BuildAllDependsAndPaths, which then drops them. So PassiveSpec reads whatever the previous calculation left behind.

Possible fix

Decide the jewel limit in one place from the build itself (socket order + Ignore Jewel Limits), and have both PassiveSpec:BuildAllDependsAndPaths and CalcSetup use it. Or rebuild the tree paths when a calculation changes any limitDisabled value. Either way the tree no longer depends on the previous calculation.

Vorherrschende Sprache
Lua
Sterne
5.5k
Forks
2.4k
Ø Merge
6 T. 14 Std.
Gemergte PRs (30 T.)
13

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus PathOfBuildingCommunity/PathOfBuilding

Alle Issues in PathOfBuildingCommunity/PathOfBuilding

Ähnliche Issues

Weitere Issues zu Lua

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.