Documentation request: an overlook at stat interpolation and how it's applied to items

[justrealmilk]

As per title

I just can't work it out myself and many implementations differ, sometimes greatly or sometimes by as little as 1.

Interpolation is pretty math heavy and frightening and while the principle is easy to grasp -- stat scales according to the displayInterpolation array -- it's hard to be sure if you've got it right when there doesn't appear to be a trusted source for what is right.

For example, The Queenbreaker has a magazine of 5 before before plug stats. Enhanced Battery has one investmentStat, Magazine. Magazine has a value of 20.

Obviously, a magazine of 25 on a linear fusion rifle is ludicrous.

Back on the item's definition and the stats key, is a statGroupHash. Its definition has a scaledStats array where we can find how to interpolate the stat values. Cool.

But do we and how do we un-scale the base stat value from item definition?

--

A lot of my understanding feels... mislead, even to me. I guess that's why I'm posting. 😅

[vthornheart-bng]

Ah, so a very important thing to understand is that some stats - particularly Magazine Size, but not necessarily limited to it - will never be 100% accurate coming from the API.

The reason for this has to do with how heavily the stat is affected by runtime scripts on top of the static calculations you're seeing with Stat Groups and the interpolation they provide. I go into a little more detail here:

https://bungie-net.github.io/multi/schema_Destiny-Definitions-DestinyItemStatBlockDefinition.html#schema_Destiny-Definitions-DestinyItemStatBlockDefinition

But the gist is that stats can be modified at will by runtime scripts, and some stats are so heavily modified in doing so that at one point back in Destiny 1 I had considered removing them entirely because they can't possibly give an accurate number. I was persuaded by the community to keep them in so that they could be used for relative comparison: but they should always be looked at as merely for comparative purposes.

It's a crappy situation, but the API will unfortunately never be able to provide accurate stats when these runtime scripts are in play.

As far as how the mods are modifying the stats (such as the Enhanced battery example), I will have to do some investigating and get back to you on that. The inaccuracies you could be seeing could very well be sourced by these runtime scripts, or it may be that we are improperly processing mods' stats before you receive them... or possibly both! I don't have the answer at this time, but I do know that Magazine Size in particular is not to be trusted as canonical. And beyond that I'll have to do some digging!

[Xalavar]

I believe I made a thread (#754) on this as well. It is exhausting to make formulas for how to handle some of these stats, especially for some of these "hidden" ones that aren't visible in-game. It's extremely difficult to believe what is and isn't real in the API sometimes and there are some parts of it that are just way too expansive to model (i.e. masterwork rolls).

For example, The Queenbreaker has a magazine of 5 before before plug stats. Enhanced Battery has one investmentStat, Magazine. Magazine has a value of 20.

Obviously, a magazine of 25 on a linear fusion rifle is ludicrous.

Back on the item's definition and the stats key, is a statGroupHash. Its definition has a scaledStats array where we can find how to interpolate the stat values. Cool.

But do we and how do we un-scale the base stat value from item definition?

Regarding some of these actual modifier values...

I've found that you have to do that sort of thing manually, but it's irritating since the in-game algorithm is different for every weapon type. For Fusion Rifles, the Liquid Coils perk modifies the Charge Time stat by -10 (which means longer charge time, which is bad). I confirmed that multiplying that value by 4 gives you the actual number of milliseconds it modifies the charge time by, and same with the Accelerated Coils perk (which modifies the Charge Time by +10).

For Linear Fusion Rifles, I found that you had to multiply the modifier Charge Time value by 3.3.

The same methodology could be applied to Magazine sizes and other stats, but I have yet to test that and I feel like there's more than just simple multiplication by one number involved in this process. Another thing is that, in the game, there is a roof peak for some stats, including Magazine, which makes these calculations a lot more difficult and the results tend to be inaccurate. I believe the maximum ammunition a Linear Fusion Rifle can hold in a single Magazine is about 8 (correct me if I'm wrong), and no matter what other perks you select to increase it, it won't go higher. I'm not sure if Weapon Mods can bypass this roof peak or not as I have yet to use any of my weapon mods in-game.

[floatingatoll]

We discussed back in the day whether it made more sense for the numeric integers to be available to us or not, specifically Magazine Size, given the unavoidable mismatch between what the API can calculate for it and the further non-public calculations performed exclusively in the game itself where the API cannot reach. At the time, the decision was to continue sharing Magazine Size — it’s useful to have it, even though it cannot and will not ever match up with the actual in-game outcomes for game architecture reasons. Should we ask Bungie to reverse that choice and hide the stat from us altogether? Or, is it useful _enough_ for everyone — given the impossibility of making it more accurate — that we should continue to request it be in the API?

…

On Dec 3, 2018, at 00:36, LordNazo ***@***.***> wrote: I believe I made a thread regarding this as well. It is exhausting to make formulas for how to handle some of these stats, especially for some of these "hidden" ones that aren't visible in-game. It's extremely difficult to believe what is and isn't real in the API sometimes and there are some parts of it that are just way too expansive to model (i.e. masterwork rolls). For example, The Queenbreaker has a magazine of 5 before before plug stats. Enhanced Battery has one investmentStat, Magazine. Magazine has a value of 20. Obviously, a magazine of 25 on a linear fusion rifle is ludicrous. Back on the item's definition and the stats key, is a statGroupHash. Its definition has a scaledStats array where we can find how to interpolate the stat values. Cool. But do we and how do we un-scale the base stat value from item definition? Regarding some of these actual modifier values... I've found that you have to do that sort of thing manually, but it's irritating since the in-game algorithm is different for every weapon type. For Fusion Rifles, the Liquid Coils perk modifies the Charge Time stat by -10 (which means longer charge time, which is bad). I confirmed that multiplying that value by 4 gives you the actual number of milliseconds it modifies the charge time by, and same with the Accelerated Coils perk (which modifies the Charge Time by +10). For Linear Fusion Rifles, I found that you had to multiply the modifier Charge Time value by 3.3. The same methodology could be applied to Magazine sizes and other stats, but I have yet to test that and I feel like there's more than just simple multiplication by one number involved in this process. Another thing is that, in the game, there is a roof peak for some stats, including Magazine, which makes these calculations a lot more difficult and the results tend to be inaccurate. I believe the maximum ammunition a Linear Fusion Rifle can hold in a single Magazine is about 8 (correct me if I'm wrong), and no matter what other perks you select to increase it, it won't go higher. I'm not sure if Weapon Mods can bypass this roof peak or not as I have yet to use any of my weapon mods in-game. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[Xalavar]

I still say we should keep it. Just because we don't know what the numbers entirely mean, that doesn't mean we shouldn't get rid of them.

[vthornheart-bng]

It's definitely something I'm torn on, personally. I hate returning data that I know will be false compared to what the game shows - but I would also hate to deny people info that they still find useful even if it's not 100% accurate.

Perhaps it'd be useful to segregate stats into "trusted" and "untrusted" - perhaps to put a boolean value on the stat definition and flag such stats when they're discovered to consistently have false values compared to what is shown in game. That might at least be a better warning to people, and would give someone something to filter on.

The ugly truth is that all stats we return are fake from the perspective of the game. The values we get and return are almost entirely divorced from the values that the game ends up using. It just happens to be that most of the places where the stats are actually shown to users end up being shown with "our" values in the places where they're displayed in the game, and others end up being shown with "their" values. The ones that show "their" values - like Magazine Size - are the ones that are obviously wrong. But we'll never get the real values for any stats, as in the stats that the sandbox itself ends up using.
It's yucky.

[vthornheart-bng]

It's also interesting philosophically. What does it mean for a stat to be "real"? Is it real if it's what the UI shows? Or is it real if it's what the underlying game engine uses? What if one is derived from the other? What if one is highly transitory and state-dependent, and the other is stable but wrong at any given moment?

It feels like it depends! For instance, "Impact" is such a fuzzy concept that its relationship to the actual underlying stat data doesn't feel as important as something that has an obvious firm purpose, like Magazine Size. Magazine Size is discrete and its specific value is more important than Impact, which is by its nature something that lacks a specific external meaning that you can directly relate to an item. (which is to say, it's almost meaningless to use Impact for anything other than relative comparisons... where Magazine Size can be used both for relative comparisons and for very specific evaluation of immediately relevant game state).

Anyways, to loop all of this back... I'll still need to take a look at what's going on, because this may not be related to the differences in script-based transformations on weapon stats. But it is interesting - and hopefully useful for those looking to use these stats - to know about their severe limitations.

[ckhicks]

FWIW, the idea of flagging specific stats as "untrusted" is interesting to me. Even if the sandbox takes over and virtually all stats fit into this category at runtime, for those building interactive/simulated values knowing the difference could mean less frustration for the user. What's that saying about "close" only counting in Grenades and Horseshoes perks? 😆

[vthornheart-bng]

I agree wholeheartedly - I think that's a definite take-away from this, and something I will see about adding to the definitions!

[floatingatoll]

Another problem to consider: the assumption that numerical comparisons are sufficient to compare guns is incorrect. If one gun’s bullet cone script applies range and aim assist differently than another gun’s bullet cone script (say, linear versus exponential curve as the cone widens), then a higher range stat on the exponential one weapon would not necessarily be “better” than a lower range stat on the linear one. This applies to _all_ stats, theoretically, because each bullet’s path is evaluated by scripts that may be unique to each gun. Cadenza-11, a green, is snappier in practice for me than Cadenza-43, a purple. It has worse numeric stats and fewer perks. There’s no reason apparent from stats alone for it to be better. Yet it is for me. Explaining this is impossible unless you consider that -11 has a different bullet script than -43, a theory upheld by the -11 flavor text itself: “A modded version of the Cadenza-43, a Guardian standby.” I like to think that Bungie is being perfectly honest and direct in that description; that what’s modded about it is the bullet cone shape, changing it from a V to a Y so that it’s perfect within optimal range and useless beyond it - precisely how the gun behaves in practice. So in practice, we can compare gross differences in numbers on lots of guns, but in reality, how they perform in-game cannot be estimated correctly from a simple numerical comparison. Recording integer values from in-game will not bring you closer to being able to evaluate “better” or “worse” for a gun except in a general sense at best (“usually more bullets”, for example). In this sense, _all_ API-published stats should be untrusted, but even if such were indicated I can’t imagine Destiny apps being willing to spend valuable UX reminding people of this. I do wish that the API’s published integer for Magazine was titled differently than the in-game statistic, so that it was immediately apparent that it’s not the same number, but that would require localizing a new string and so we won’t see that any time soon or likely at all.

…

On Dec 6, 2018, at 12:47, CK Hicks ***@***.***> wrote: FWIW, the idea of flagging specific stats as "untrusted" is interesting to me. Even if the sandbox takes over and virtually all stats fit into this category at runtime, for those building interactive/simulated values knowing the difference could mean less frustration for the user. What's that saying about "close" only counting in Grenades and Horseshoes perks? 😆 — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.