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

Aberta
  • Algo errado?
#10,430 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 8 dias

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
55/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
lua
Domínio
backend, game-dev

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Lua
Estrelas
5.5k
Forks
2.4k
Merge médio
6d 14h
PRs com merge (30d)
13

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de PathOfBuildingCommunity/PathOfBuilding

Todas as issues de PathOfBuildingCommunity/PathOfBuilding

Issues semelhantes

Mais issues de Lua

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.