Plugs are kind of a nightmare #735
Comments
|
(Cancel that, sorry, I misread something.) |
|
There's also some inconsistency in the way Plugs/sockets are presented from the instance item. For example
This is an excerpt from an actual item. The vast majority of the time, However, this is not always true. In the case of Masterworks, Similarly, in the case of Shaders, In the case of Mods, This is a minor gripe, but honestly the wildly varying/inconsistent nature makes for a lot of boilerplate edge case checking code. |
|
Yes indeed, the complexity of the sockets code reflects the complexity of the potential states in which an item can have socket data combined with a desire to minimize the potential amount of data that we have to return. I deeply empathize with your frustration, as we've felt the same working on our own features as well as in creating the API itself. Sockets were originally intended to be a fairly simple system - a reduction in complexity from the extremely complex Talent Grid system of Destiny 1 - but quickly expanded into something that is - for both you and we - pretty tedious to use. (it is a real textbook example of feature creep: and unfortunately, we have few options for hiding this increase in complexity on the game side without either being less comprehensive or creating a great deal of redundancy in the data we return from requests, which I will try to go into in the write-up so as to give a better understanding for why we don't abstract the game's complexity for these features as well as I wish we would) I'll try to give a more comprehensive write-up of this information about how Sockets work, and how you can get at the information you're looking for: but indeed, there isn't an easy to use view of sockets. I will do my best to write an article to use as a guide, however: I think it's reached a level of complexity where it's downright frustrating to use without one, and that sucks... and particularly sucks given that we don't have a guide for it. Just to make sure I'm covering all the bases of what you're interested in when I make this write up, you're wondering about:
Does anyone else (yourself included) have any other questions/topics on the subject that you'd like me to cover in this writeup? I'm eager to share what I can! |
|
Also, on a completely unrelated side topic, I love your Github icon. Tecmo Bowl for life. |
|
It would be invaluable to have a complete walkthrough for two or three
wildly different items that, between them, make use of all known sockets
'features'.
…On Fri, Oct 19, 2018 at 3:21 PM Alex Tennant ***@***.***> wrote:
What do the “empty” sockets represent? i.e. not initialHash, reuseable and
random plugs.
How are curated rolls represented? Is it always the initialHashes? What’s
the best way of identifying something with a curated roll?
How can you tell which masterworks an item can actually roll with? It
seems the item definitions contain a lot of “impossible” masterworks.
I’m sure have more, these are what come to mind right now.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#735 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAFqDEIU_QeBU0T96qldN9Y7ejdzMzGNks5umlBggaJpZM4Xxapn>
.
|
|
What do the “empty” sockets represent? i.e. no initialHash, reuseable and random plugs. How are curated rolls represented? Is it always the initialHashes? What’s the best way of identifying something with a curated roll? How can you tell which masterworks an item can actually roll with? It seems the item definitions contain a lot of “impossible” masterworks. I’m sure have more, these are what come to mind right now. |
|
Yes, thank you both for your input! Anyone with more, please bring them forward here! |
|
Tacking on to adtennant here, when an item is a curated roll ( no changeable perks, fully masterworked) it appears to be that the curated roll is represented by the initial plug hash values. Are these values also capable of being random rolls? Or is it limited exclusively to the random list of plugs provided (forgot the property name, can't look it up right now) This was asked earlier on GitHub, but there isn't a way to have in the api how many random rolls a given column can contain correct? |
|
Thank you, good questions as well! |
|
Okay, this is my outline so far for what needs to be covered. It's going to take me some time to fill this all out, but where I could I tried to include info in this summary that might help with some of the more direct questions:
|
|
Ah, there's one more thing in here too not relevant to the documentation: it sounds like we're having issues with item category hashes. Those ought to be a reliable way to find out what items are mods, and at least in some vague level what type of mods they are. If you're finding miscategorized ones, something's broken there that we can fix! We won't support the old/obsoleted mods anymore, but we can fix any miscategorized 4.x plugs! |
|
This. Is. Epic. Dropping a comment here to cheer everyone on and make sure I get notifications about this one in case I miss something later. 👍 |
|
The object “Five of Swords” is a stellar example of maximum plaid, in case it comes in handy later on.
… On Oct 19, 2018, at 20:52, CK Hicks ***@***.***> wrote:
This. Is. Epic. Dropping a comment here to cheer everyone on and make sure I get notifications about this one in case I miss something later. 👍
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
On another note, is there a particular reason why plugs are in the |
|
@floatingatoll Good call, that's another whole way that sockets are being used! I'll add that to the list. @xxbiohazrdxx That's a very good question with a very unfortunate answer. The short answer is that, very early on, the game designers decided that almost anything they wanted in the game could be represented as either an Item or a Vendor. The implication of this original decision made before Destiny 1 went public lives on today in features that are more-or-less bolted onto both concepts. The long answer is that Plugs reuse a lot of properties shared between the various types of things that the game considers to be items: enough that they didn't want to build separate systems to handle the very similar functionality, so Plugs became a "feature" that an item can have rather than its own entity. Though in practice, any item that is a Plug doesn't get treated in any context other than as a plug (even though plugs themselves get treated in very different ways, as eluded to in the outline above). Theoretically, some cruel designer could someday make a weapon that could be plugged into another weapon, or a ship that could be plugged into a sparrow. Thankfully, they haven't done that yet. As to why we don't hide that in the API, there's a couple of reasons: most of them having to do with our own time and maintenance constraints, that also make it easier for us to treat them the same way as the game's content treats them. If I had my druthers, or a larger staff working on the API, or even a promise that the concept of Plugs won't expand further than it already has (I have no such promise, and thus can't make that promise), I'd love to look into making our own "derivative definitions" that treat plugs as separate entities to external users. However, we have two problems with that: (1) breaking backward compatibility, and (2) derivative definitions have often bitten us in the butt in the API: and I'm very hesitant to do so unless I get solid assurances that the given feature is likely to not change in such a way that it breaks our derivative definitions. Milestones are an interesting example of where we attempted to create a derivative definition because the source items were basically unusable for the stated purposes from an API perspective, and the fact that we've done so has bitten us in the butt over and over again as the concept of what a milestone is and the data it holds changes, leaving us scrambling to try and maintain backwards compatibility while exposing whatever new functionality or variability has been introduced. Users of the Destiny 1 API will remember that we made the same mistake with "Advisors," as well as when we tried to hide some of the complexity of the original talent grids only to have core assumptions change out from under us at the whim of game design: changes that required us to make sudden backwards-compatibility breaking changes in order to fix the data we were returning. |
|
If you want a good laugh, I go into the Vendor side of this bolting-on here: https://bungie-net.github.io/multi/schema_Destiny-Definitions-DestinyVendorDefinition.html |
|
Hey since you brought up potentially miscategorized plugs
I think it's a little silly that an empty mod and damage mod have a different category hash, but I can kind of understand why. However, it makes no sense why Backup Mag is completely different and in it's own category. |
|
I would guess it has to do with magazine scripting being especially special (since D1). |
|
Just as an update on this, I've had 0 time to work on the aforementioned article. I'm hoping to loop back to this as work begins to settle down for the holiday season. My plan is to bring back the winter wishlist and make the creation of this document a priority on that list. |
|
What's the current best documentation or example of Plugs? Trying to build a tool that relies heavily on this functionality and the caveats with the far simpler Perks are giving me migraines. |
This is gonna be a long one, so bear with me please.
Let's say I want to parse all of the plugs for a particular instance of an item. Specifically, I would like to find the Weapon Mods for that item. Let's take a look at a table of the Weapon Mods in the manifest.
How would I do that? At first glance it looks like the itemType and itemSubType might work, but the combination of
itemType == 19 and itemSubType == 0is actually valid for many, many other plugs and not just Weapon Mods (not to mention there's a single 20 in there for itemType).
I can't use the
plug.plugCategoryHasheven though it looks promising. Pre 4.x/Forsaken mods have a value of1466776700....except when they don't. Kinetic Damage Mod and Weapon Attack Mod are different. Post 4.x/Forsaken mods have aplug.plugCategoryHashof either510594033or974142739unless there is no mod, in which case it is3945646995.It looks like the easiest way to get only Weapon Mods is
itemTypeDisplayName == "Weapon Mod". That's not ideal, but it works.However, this doesn't carry over to other categories. Let's take Armor Mods (Note that I have significantly truncated this and the proceeding tables because we don't need to see every plug to get the point)
The hashes are a bit better here, 3.x Armor Mods have a
plug.plugCategoryHashthat definitively mark this Plug as being an Armor Mod and for a particular item/bucket. This isn't super helpful if we want to find all armor mods for all slots, for that we can instead do aitemTypeDisplayName.contains("Armor Mod")or perhapsplug.plugCategoryIdentifier.startsWith("enhancements").Masterworks?
Check and see if
plug.plugCategoryIdentifier.contains("masterwork")then also see ifplug.plugCategoryIdentifier.startsWith("v4")so I know to query the manifest forinvestmentStats[0].statTypeHashto get the localized name of the Masterwork stat.How about Shaders?
This one is easy! Every shader in the game has a
plug.plugCategoryHashof2973005342! I wish all the plugs were like this!I realize that the actual data that the API is retrieving may very well may be beyond your control, but if there was some kind of massaging that could be done before it is returned would make Plugs a lot easier to use. An enumerator for the types of Plugs and honestly just some consistency of which field I should be looking at to determine exactly what the Plug is.
The text was updated successfully, but these errors were encountered: