'Legacy' items policy, re:patch 0.10.5

"

Phaeded написал:

That's the first time I read a GGG post and had to make sure which Mr. Wilson was writing it. You're full of shit on this one Chris. You can't retro-buff and not retro-nerf. And if you are going to do that, you have to give us a WAY better reason than this load of crap.

Those "time-limited" items can't be had any other way. Silverbranch can still be found, just in a nerfed version. So your argument is really weak.

Just so you don't need to check, I'm not Chris, or any other Wilson. I can't explain the reasoning behind this specific decision, because I didn't make it, but I can help show how other factors then buff/nerf are at play here.

"

KoTao написал:

If you can buff current volls, you can nerf current silverbranches. That reply didnt make much sense.

And why are you nerfing silverbranch anyway? There are plenty of uniques that enable players to faceroll early content- why target one in particular, and why now?

You might also want to reconsider the precedent youre setting here. Then again, perhaps this is just another in a long line of planned copy pastes from d2. Share the reasons behind this decision with us?

There's a lot of discussion going on in here about retroactively changing things, and people making claims about what can/can't be done, so I'm going to clear some of those up.

Volls:
With Voll's, we change what stat that particular mod gave. Anytime we do this, it will be retroactive will all items with that mod - anytime an item is loaded from the database, it stores which mods it has, and for each mod, the values of each stat in that mod. It doesn't store what the stats are since that would be a waste of space - those are looked up in the game data based on which mod it is. The items store that they have the mod "UniqueVollsPowerChargeCrit" (name made up for example purposes) with the stat value "1" (in this case a non-zero value means 'do this', because it's a boolean stat - you either gain the charges or you don't).
Before the patch, loading this item from the database would cause a lookup to discover that the mod "UniqueVollsPowerChargeCrit" has one stat, which is "power_charge_on_crit", and thus the item is given a value of "1" in that stat.
After the patch, that same lookup is done, but we changed what stat was associated with that mod - instead of "power_charge_on_crit", that mod now has the stat "power_charge_for_each_enemy_you_crit", which has different behaviour, so the item, when loaded, is given the value of 1 in this stat instead. The stored item wasn't changed, but what stat is associated with that mod did, and since all items use the same data for that, that can't not be retroactive.

We could instead have disabled Voll's from dropping, made a new unique with the same base type and name, etc, but with a new mod for the new stat, instead - in that case the 'new Voll's' would have the new stat and mod, and the 'old Voll's', which would technically be a different unique that no longer drops, would have the old stat and mod, which in theory would allow us to emulate non-retroactive changes, but over time that would get more and more problematic to maintain as the list of 'legacy' mods that are kept in data only for non-dropping old items increases.

Silverbranch
In the case of Silverbranch, as many of you will have concluded from my above explaination, we didn't change what stat it uses, but what value the mod could roll. When and item gains a mod, the value of each stat is rolled within that mod's value range. Previously, for Silverbranch, that value was 2-2, so all of them had +2 to bow gems. Post-patch, it's 1-1, so all have +1.
Existing items are already in the database, stored with the correct mod, and with the value of "2" for that stat, so they still have +2 - when loaded, they get the mod, look what stat that mod gives, and then apply the stored value to that stat. The mod's range was only checked when the stat was rolled, so they load with the "2" value they were stored with.
It's possible for us to make this kind of change retroactively, and this has been done in the past, but it involves a bunch of work setting up stuff to upgrade all items to a new version, and defining that upgrade code as checking for that particular mod and changing the stored value for it if present. We usually use these 'migrations' for more fundamental changes (such as when skill gems first got quality, we had to migrate all the items to a new version and have that migration add the capability for quality to all existing items that were skill gems). It takes a bit of work and a lot of testing to make very sure there's no corner case that will break items, so we don't usually do these just to change mod values unless absolutely necessary.

Skills:
These have been brought up a bit in the thread, so I'll discuss those as well. Gems don't have stats. All a gem has is a level, and what effect it grants - which is either and active skill or a support effect. This is looked up in a big table, which stores all the stats a particular skill/support has at each possible level, and the values of those stats, as well as what stats it gets fro quality, and how much per point. When we change the stats or values of a skill/support, we're changing that table, so similar to the mod case, it has to be retroactive, as the new and old gems are identical - we're just changing the info they both look up. This is why rebalancing skills always applies to existing gems - we change the skill the gem grants, not anything about the gem item itself.

So regardless of the desirability/undesirability of "legacy" items, which I'm not qualified to comment on, these changes took the form that they'd naturally take if we just changed those things, and it would have required a bunch of extra work to make the Silverbranch change be retroactive, or even more work to make the Voll's one not be. I can't say whether or to what degree other factors, such as wanting or not wanting legacy items also factored into the decision, but this hopefully explains why these changes don't indicate something explicitly being done for one change and not for another - they're different kinds of changes with different consequences regarding existing items.