modlist: accumulate values when same mod appears in multiple sources

[wigust]

Previously, when the same mod was generated from both explicit and implicit sources, the explicit value would be overwritten by the implicit one, losing the explicit contribution.

Change SumModGenerator::Generate() to add the new value to the existing entry when the mod name already exists in the output map, rather than overwriting it. This ensures both explicit and implicit mod values are combined correctly.

For example, this shield:

Item Class: Shields
Rarity: Rare
Vengeance Barrier
Pinnacle Tower Shield
--------
{ Implicit Modifier — Life }
+24 (20-30) to maximum Life
--------
{ Prefix Modifier "Stout" (Tier: 7) — Life }
+61 (55-69) to maximum Life

Before the patch, the mod table would incorrectly contain only 24 (the implicit value), discarding the explicit +61 contribution. After this fix, the values accumulate correctly to 85 total maximum Life.

[gerwaric]

Pseudomods!

They are the bane of my existence.

The good news is that mod summing is already implemented with pseudomods such as +# total to Strength. See src/pseudomods.h and src/pseudomods.cpp. The pseudomods acquisition supports are listed in the v0.16.0 release notes.

I apologize; this is going to be a long reply. I'm very glad to see you interested in the project. The fault is mine for not documenting features, because acquisition is not easy to figure out.

There's almost no way to discover pseudomod suport because (a) there's no documentation and (b) the mod search box autocomplete is just absolutely terrible to use. Absolutely terrible. It's slow. It's clunky. It rarely suggests the modifier you are looking for. I wish I could make it behave half as well as the mod search on the trade site. (This is in the works with a full-rewrite of acquisition I'm hoping to release before POE2 comes out in December).

Anyhow, here's an example of how a pseudomod search looks in practice:

Notice that I'm filtering for +90 to strength, which you can't get without adding in +36 to all Attributes.

Also notice the modifier text, +# to total Strength, which isn't just +# to Strength. That was a choice I made to follow the convention of the trade site. This means searching for +# to Strength is like searching for the explicit strength mod, while searching for total strength sums all sources of strength, such as +# to Strength and Intelligence as well as +# to all Attributes.

Another caveat is that acquisition only supports a subset of the pseudomods available on the trade site. That's partly because there are some pseudomods that aren't just straightforward summation. For example, +# to Strength should impact +# total to maximum Life, but there's a scaling factor involved.

Issue #31 goes into a little more detail.

The real fix for all of this is a rewrite of how acquisition stores and filters modifiers. That's coming, but it's part of a ground-up rewrite and probably 2-3 months away.

[gerwaric]

By the way, you are welcome to fork acquisition and do your own thing if you prefer. My ONLY request is that you leave the networking and rate limiting code alone. This is because GGG blacklisted acquisition in 2023 for rate limit violations, which affected everyone who used it. (Fixing that was my first contribution, and also my first time writing c++ since school).

Otherwise, you are welcome to go wild. Actually, please do! While I'm working on the rewrite, I'm not planning to add new features. Bugs will be evaluated on a case-by-case basis. Sometimes they are quick fixes. However, if you find a bug that leads to rate limit violations, I will probably drop everything and take time off work to fix it.

Also, if you have an idea for a feature or found a limitation or bug, please create an issue. I might be able to help before you spend time on a feature or bugfix yourself.

[wigust]

@gerwaric thanks! I did notice those pseudo-mods in the code, but I didn't dig deep enough. Appreciate the explanation! I've updated the commit in case it's useful before the rewrite.

[gerwaric]

@wigust your approach of summing identical mods is also useful, and it's not something the trade site supports. On the trade site you either search for a calculated pseudomod, or a specific kind of mod such as explicit, implicit, fractured, enchanted, crafted, etc.

I am still super jealous of the trade site's mod search field, but the rewrite will probably have a JS/TS frontend, so I'm hopeful claude will be able to reverse engineer whatever the trade site is doing, because I gave up trying to make it work in c++/Qt.

[wigust]

Copied pseudo mod name from the trading site to guarantee an exact match.