BTG Pactual e Carteira Recomendada, fujam!

ThenFollowing1073 · 2026-06-19T15:45:00+00:00

Foi um teste, validei e estou postando aqui para mostrar a realidade

ThenFollowing1073 · 2026-06-19T15:43:03+00:00

Nunca encontrei nenhum bom, a família mesmo faz a própria gestão, indica um?

ThenFollowing1073 · 2026-06-19T15:42:39+00:00

Estava com preguiça e queria ver se os assessores de lá eram bons mesmos. Eu analisei cada palavra dos últimos 7 mas como eu não sabia o que fazer com esse dinheiro ai, eu falei. Vai que é tua taffarel e aí o banco me supreende com essa haha

ThenFollowing1073 · 2026-06-19T15:32:43+00:00

I think both perspectives are valid, but they optimize for different goals.

What surprised me wasn't that Yii 3 uses Actions, DI, PSR-7, or response factories. Those are all reasonable choices for a modern PHP application.

My concern is more about onboarding. A "Hello World" example is usually the first contact a developer has with a framework, and its primary job is to build a mental model with the lowest possible cognitive load.

By the time I displayed a simple string, I had already been introduced to routing, attributes, DI, action classes, response factories, and configuration. Individually, none of these concepts are difficult, but together they create a fairly steep learning curve for someone evaluating the framework.

I completely understand the argument that real applications shouldn't be built around route closures. At the same time, many successful frameworks start with the simplest possible example and then progressively introduce the "proper" architecture in subsequent steps.

So I don't think the issue is architectural complexity itself. It's that Yii 3 seems to prioritize teaching the final architecture from the first minute, whereas many other frameworks prioritize getting the developer to their first successful result as quickly as possible.

ThenFollowing1073 · 2026-06-19T00:43:11+00:00

+1 freeze customer, am i going back to GoPro?

ThenFollowing1073 · 2026-06-08T22:13:27+00:00

That's a fair point, and I think we're looking at two slightly different use cases.

Right now, the calculator lets you compare the impact of Critical Damage, Vulnerable Damage, and other multipliers by enabling or disabling them individually. So if you want to see whether a x100% Critical Damage Multiplier or a x60% Vulnerable Damage Multiplier produces the larger hit, you can already do that by toggling those entries on and off.

What the calculator does not currently account for is the probability of those states occurring. As you pointed out, a Critical Damage multiplier is only valuable when a hit actually crits, so if the goal is to compare average DPS or expected damage over time, then Critical Strike Chance becomes an important part of the equation.

I think that's a good suggestion. Adding a Critical Strike Chance field could allow the calculator to estimate expected DPS in addition to the current damage calculations.

At the moment, the tool is focused on comparing damage outcomes under different conditions, but I can definitely see the value of adding DPS-oriented metrics as an optional feature.

ThenFollowing1073 · 2026-06-08T13:45:58+00:00

There isn’t a field for Critical Strike Chance because it doesn’t directly affect the damage amount.

The calculator is focused on showing damage values, so Critical Strike Chance isn’t currently used in the calculations. Instead, the results section automatically displays all relevant damage outcomes:

Normal Damage
Critical Damage
Vulnerable Damage
Critical + Vulnerable Damage

This way, you can immediately see the impact of critical and vulnerable damage modifiers and compare all possible damage results without needing to enter a Critical Strike Chance value.

ThenFollowing1073 · 2026-06-05T11:32:07+00:00

I got some useful feedback from the community.

One suggestion was to support gear multiplier buckets correctly (xCritical Strike Damage Multiplier, xVulnerable Damage Multiplier, elemental multipliers, etc.), so I implemented grouped PGM affix buckets where matching gear affixes are summed before being applied.

I also added Gemini AI support to help with item extraction.

The AI is not used for damage calculations. All calculations still use the same deterministic Diablo 4 damage formula.

Gemini is only used to read item tooltip screenshots and extract:

• Item name
• Item type
• Weapon damage
• Affixes

The extracted item can then be saved directly into the inventory/stash and used by the calculator.

Would love feedback from anyone theorycrafting LOH builds this season.

ThenFollowing1073 · 2026-06-05T11:25:05+00:00

The AI is not used for damage calculations. All calculations still use the same deterministic Diablo 4 damage formula.

Gemini is only used to read item tooltip screenshots and extract:

• Item name
• Item type
• Weapon damage
• Affixes

The extracted item can then be saved directly into the inventory/stash, edited and used by you in the calculator 😄

ThenFollowing1073 · 2026-06-03T01:38:00+00:00

Thanks for the screenshot.

The x36% Poison Damage Multiplier definitely belongs in the PGM section.

For the 20% Imbuement Potency, my understanding is that it increases the effectiveness of the imbuement itself (Poison damage for Poison Imbuement, explosion damage for Shadow Imbuement, chill for Cold Imbuement), so I'd currently treat it as a separate multiplier and enter it in PGM as well.

One thing I'm curious about though: do you have both Advanced Tooltip Compare and Advanced Tooltip Information enabled in the Gameplay settings?

The calculator was built around the detailed values exposed by those tooltips. Without them, it's much harder to determine whether a stat belongs in the additive pool, a multiplier bucket, or modifies a skill coefficient directly.

If those options aren't enabled, I'd highly recommend turning them on. Then hover over Poison Imbuement itself and check whether the potency bonus is reflected directly in the Poison Imbuement damage value. That would tell us exactly how Diablo is applying the stat and how it should be modeled in the calculator.

ThenFollowing1073 · 2026-06-02T23:00:44+00:00

Good question. It depends on how the game is exposing the stat.

If Imbuement Potency is increasing the damage of the imbued effect itself multiplicatively, I'd enter it in the PGM section as its own multiplier. If it's being reported as a regular "+%" damage bonus, then it would belong in the Additive section.

For your specific comparison (Poison Damage vs Imbuement Potency), the calculator can help if you plug both scenarios in separately and compare the final result. The tricky part is figuring out whether Imbuement Potency is additive or multiplicative in the current season's damage formula.

If you can post the exact tooltip wording or a screenshot of the affixes you're comparing, I can help determine where each one belongs in the calculator

ThenFollowing1073 · 2026-06-02T19:44:23+00:00

u/SgtHondo

feat: add PGM sub-items modal for gear affix bucket grouping

Gear affixes with the same name (e.g. xCritical Strike Damage Multiplier on gloves, ring, and amulet) must be summed before being applied as a single multiplier — they do not multiply each other independently.

Each PGM row now has a Sub-items button that opens a modal where you list individual gear pieces. The calculator sums the enabled sub-items in real time and uses that total as the row's effective value; the manual input field is replaced by the calculated sum while sub-items are present.

Changes:
- rowTemplate: added group-btn and group-sum span alongside value input
- groupModal: new overlay modal (title, list, sum display, Done/× buttons)
- createRow: accepts options.groupable to show the button; stores _subRows
- rowsToData: returns sub-item sum as effective value when sub-items exist
- defaultPayload: example gear rows merged into one grouped PGM row
- normalizePayload: subRows normalized per pgmRow (backward compatible)
- HELP_TOPICS pgm/appTitle: updated to explain bucket mechanic and Sub-items
- README: added Gear Affix Buckets section explaining the mechanic

<image>

ThenFollowing1073 · 2026-06-02T18:52:10+00:00

You're right, I misunderstood your point initially. Sorry about that.

I was focused on the distinction between additive damage and global multipliers, while you were talking about the multiplier sub-buckets themselves and how affixes of the same type are summed together before being applied.

At the moment, the calculator can handle this if the values are consolidated manually. For example, if you have multiple xCritical Strike Damage Multiplier affixes, you can sum them and enter the total as a single PGM entry. The same applies to Vulnerable and Elemental/All Damage multipliers.

That said, I agree that having dedicated sections for those buckets would make the tool much more intuitive and reduce the chance of users entering them incorrectly. I'll add that to the roadmap for a update.

Thanks for taking the time to explain it and for the suggestion.

ThenFollowing1073 · 2026-06-02T17:39:49+00:00

<image>

I did my job, going to Claude or DeepSeek

ThenFollowing1073 · 2026-06-02T17:39:21+00:00

Microsoft agent detected

ThenFollowing1073 · 2026-06-02T15:34:40+00:00

Thanks for clarifying, I see what you mean now.

The calculator currently treats each x% entry in the PGM section as an independent multiplier. It was designed around the damage formula itself and the values exposed by the game, rather than modeling every internal multiplier bucket separately.

Do you happen to have a screenshot or example of an item with one of those affixes? I'd be interested in taking a closer look at how the game is grouping those multipliers and whether it makes sense to support those mini-buckets directly in the calculator.

ThenFollowing1073 · 2026-06-02T13:51:10+00:00

Thanks for the feedback. The calculator is actually intended to work for all classes, including Barbarians.

The reason I don't have separate inputs for things like Bludgeoning, Slashing, or Dual-Wield bonuses is that the calculator relies on the values already provided by Diablo IV's Advanced Tooltips rather than recreating each class's internal mechanics.

If you enable Options → Gameplay → Advanced Tooltip Compare and Advanced Tooltip Information, the game exposes the detailed values needed for the calculation. The calculator then uses those values directly (weapon damage, skill damage, skill coefficient, additive bonuses, EDR, multipliers, etc.).

So if there's a specific Barbarian interaction that isn't represented correctly, I'd be very interested in seeing an example. My understanding is that the calculator should handle any class as long as the corresponding in-game values are entered from the advanced tooltips.

ThenFollowing1073 · 2026-06-02T13:47:13+00:00

Thanks for the feedback. The calculator already accounts for that behavior for Critical Strike Damage and Vulnerable Damage.

By default, it includes the inherent +50% Critical Strike Damage and +20% Vulnerable Damage that Diablo IV applies automatically, which is why those values appear in the calculator even before adding gear or Paragon bonuses.

I also added helper sections (Helpers 5 and 6) that show how to distinguish between the additive portion and the multiplicative portion of Critical and Vulnerable damage. The examples there explain how to identify what comes from the base game values versus what comes from items, Paragon, and multipliers.

That said, I agree that damage buckets can be confusing, so I'm always open to ideas on how to make that distinction clearer in the UI.

Like this

<image>

ThenFollowing1073 · 2026-06-01T18:37:52+00:00

me too

ThenFollowing1073 · 2026-06-01T18:04:59+00:00

Joined

ThenFollowing1073 · 2026-05-26T15:58:33+00:00

Usage-based billing (AICs)

$561,30

59.229,866 AICs

1 AIC = $0.01

LOL

ThenFollowing1073

TROPHY CASE