Represents the "Live" data that we can obtain about a Character's status with a
specific Activity. This will tell you whether the character can participate in
the activity, as well as some other basic mutable information. [...]
These Art Elements are meant to represent one-off visual effects overlaid on the
map. Currently, we do not have a pipeline to import the assets for these
overlays, so this info exists as a placeholder for when such a pipeline exists (
if it ever will)
Nodes on a graph can be visually connected: this appears to be the information
about which nodes to link. It appears to lack more detailed information, such as
the path for that linking.
The actual activity to be redirected to when you click on the node. Note that a
node can have many Activities attached to it: but only one will be active at any
given time. The list of Node Activities will be traversed, and the first one
found to be active will be displayed. This way, a node can layer multiple
variants of an activity on top of each other. For instance, one node can control
the weekly Crucible Playlist. There are multiple possible playlists, but only
one is active for the week.
This is the position and other data related to nodes in the activity graph that
you can click to launch activities. An Activity Graph node will only have one
active Activity at a time, which will determine the activity to be launched (and,
unless overrideDisplay information is provided, will also determine the tooltip
and other UI related to the node)
Nodes can have different visual states. This object represents a single visual
state ("highlight type") that a node can be in, and the unlock expression
condition to determine whether it should be set.
Represents a single state that a graph node might end up in. Depending on what's
going on in the game, graph nodes could be shown in different ways or even
excluded from view entirely.
A point of entry into an activity, gated by an unlock flag and with some more-or-
less useless (for our purposes) phase information. I'm including it in case we
end up being able to bolt more useful information onto it in the future. [...]
This definition represents an "Activity Mode" as it exists in the Historical
Stats endpoints. An individual Activity Mode represents a collection of
activities that are played in a certain way. For example, Nightfall Strikes are
part of a "Nightfall" activity mode, and any activities played as the PVP mode "
Clash" are part of the "Clash activity mode. [...]
If the activity is a playlist, this is the definition for a specific entry in
the playlist: a single possible combination of Activity and Activity Mode that
can be chosen.
Represents a status string that could be conditionally displayed about an
activity. Note that externally, you can only see the strings themselves.
Internally we combine this information with server state to determine which
strings should be shown.
Basic identifying data about the bubble. Combine with
DestinyDestinationBubbleSettingDefinition - see DestinyDestinationDefinition.
bubbleSettings for more information.
This component holds activity data for a character. It will tell you about the
character's current activity status, as well as activities that are available to
the user.
This component returns anything that could be considered "Progression" on a user:
data where the user is gaining levels, reputation, completions, rewards, etc...
Only really useful if you're attempting to render the character's current
appearance in 3D, this returns a bare minimum of information, pre-aggregated,
that you'll need to perform that rendering. Note that you need to combine this
with other 3D assets and data from our servers. [...]
By public demand, Checklists are loose sets of "things to do/things you have
done" in Destiny that we were actually able to track. They include easter eggs
you find in the world, unique chests you unlock, and other such data where the
first time you do it is significant enough to be tracked, and you have the
potential to "get them all". [...]
The properties of an individual checklist item. Note that almost everything is
optional: it is highly variable what kind of data we'll actually be able to
return: at times we may have no other relationships to entities at all. [...]
A shortcut for the fact that some items have a "Preview Vendor" - See
DestinyInventoryItemDefinition.preview.previewVendorHash - that is intended to
be used to show what items you can get as a result of acquiring or using this
item. [...]
This is a reference to, and summary data for, a specific item that you can get
as a result of Using or Acquiring some other Item (For example, this could be
summary information for an Emote that you can get by opening an an Eververse Box)
See DestinyDerivedItemCategoryDefinition for more information.
Human readable data about the bubble. Combine with DestinyBubbleDefinition - see
DestinyDestinationDefinition.bubbleSettings for more information. [...]
On to one of the more confusing subjects of the API. What is a Destination, and
what is the relationship between it, Activities, Locations, and Places? [...]
Display Categories are different from "categories" in that these are
specifically for visual grouping and display of categories in Vendor UI. The "
categories" structure is for validation of the contained items, and can be
categorized entirely separately from "Display Categories", there need be and
often will be no meaningful relationship between the two.
Many Destiny*Definition contracts - the "first order" entities of Destiny that
have their own tables in the Manifest Database - also have displayable
information. This is the base class for that display information.
Characters can not only have Inventory buckets (containers of items that are
generally matched by their type or functionality), they can also have Equipment
Slots. [...]
If a Destiny Profile can't be returned, but we're pretty certain it's a valid
Destiny account, this will contain as much info as we can get about the profile
for your use. [...]
These definitions represent Factions in the game. Factions have ended up
unilaterally being related to Vendors that represent them, but that need not
necessarily be the case. [...]
Mostly for historical purposes, we segregate Faction progressions from other
progressions. This is just a DestinyProgression with a shortcut for finding the
DestinyFactionDefinition of the faction related to the progression.
Gender is a social construct, and as such we have definitions for Genders. Right
now there happens to only be two, but we'll see what the future holds.
An Inventory (be it Character or Profile level) is comprised of many Buckets. An
example of a bucket is "Primary Weapons", where all of the primary weapons on a
character are gathered together into a single visual element in the UI: a subset
of the inventory that has a limited number of slots, and in this case also has
an associated Equipment Slot for equipping an item in the bucket. [...]
A list of minimal information for items in an inventory: be it a character's
inventory, or a Profile's inventory. (Note that the Vault is a collection of
inventory buckets in the Profile's inventory) [...]
So much of what you see in Destiny is actually an Item used in a new and
creative way. This is the definition for Items in Destiny, which started off as
just entities that could exist in your Inventory but ended up being the backing
data for so much more: quests, reward previews, slots, and subclasses. [...]
Defines a specific stat value on an item, and the minimum/maximum range that we
could compute for the item based on our heuristics for how the item might be
generated. [...]
In an attempt to categorize items by type, usage, and other interesting
properties, we created DestinyItemCategoryDefinition: information about types
that is assembled using a set of heuristics that examine the properties of an
item such as what inventory bucket it's in, its item type name, and whether it
has or is missing certain blocks of data. [...]
The base item component, filled with properties that are generally useful to
know in any item request or that don't feel worthwhile to put in their own
component.
If an item has a related gearset, this is the list of items in that set, and an
unlock expression that evaluates to a number representing the progress toward
gearset completion (a very rare use for unlock expressions!)
If an item is "instanced", this will contain information about the item's
instance that doesn't fit easily into other components. One might say this is
the "essential" instance data for the item. [...]
Represents a socket that has a plug associated with it intrinsically. This is
useful for situations where the weapon needs to have a visual plug/Mod on it,
but that plug/Mod should never change.
If the item can exist in an inventory - the overwhelming majority of them can
and do - then this is the basic properties regarding the item's relationship
with the inventory.
Represents a "raw" investment stat, before calculated stats are calculated and
before any DestinyStatGroupDefinition is applied to transform the stat into
something closer to what you see in-game. [...]
An item can have objectives on it. In practice, these are the exclusive purview
of "Quest Step" items: DestinyInventoryItemDefinitions that represent a specific
step in a Quest. [...]
Items can have objectives and progression. When you request this block, you will
obtain information about any Objectives and progression tied to this item.
Plugs are non-instanced items that can provide Stat and Perk benefits when
socketed into an instanced item. Items have Sockets, and Plugs are inserted into
Sockets. [...]
Items like Sacks or Boxes can have items that it shows in-game when you view
details that represent the items you can obtain if you use or acquire the item. [...]
An item's "Quality" determines its calculated stats. The Level at which the item
spawns is combined with its "qualityLevel" along with some additional
calculations to determine the value of those stats. [...]
Used in a number of Destiny contracts to return data about an item stack and its
quantity. Can optionally return an itemInstanceId if the item is instanced - in
which case, the quantity returned will be 1. If it's not... uh, let me know okay?
Thanks.
The response object for retrieving an individual instanced item. None of these
components are relevant for an item that doesn't have an "itemInstanceId": for
those, get your information from the DestinyInventoryDefinition.
Some items are "sacks" - they can be "opened" to produce other items. This is
information related to its sack status, mostly UI strings. Engrams are an
example of items that are considered to be "Sacks".
Properties of a DestinyInventoryItemDefinition that store all of the information
we were able to discern about how the item spawns, and where you can find the
item. [...]
This defines information that can only come from a talent grid on an item. Items
mostly have negligible talent grid data these days, but instanced items still
retain grids as a source for some of this common information. [...]
A "Location" is a sort of shortcut for referring to a specific combination of
Activity, Destination, Place, and even Bubble or NavPoint within a space. [...]
Many actions relating to items require you to expend materials: - Activating a
talent node - Inserting a plug into a socket The items will refer to material
requirements by a materialRequirementsHash in these cases, and this is the
definition for those requirements in terms of the item required, how much of it
is required and other interesting info. This is one of the rare/strange times
where a single contract class is used both in definitions and in live data
response contracts. I'm not sure yet whether I regret that.
Represents a runtime instance of a user's milestone status. Live Milestone data
should be combined with DestinyMilestoneDefinition data to show the user a
picture of what is available for them to do in the game, and their status in
regards to said "things to do." Consider it a big, wonky to-do list, or Advisors
3.0 for those who remember the Destiny 1 API.
Sometimes, we know the specific activity that the Milestone wants you to play.
This entity provides additional information about that Activity and all of its
variants. (sometimes there's only one variant, but I think you get the point)
Represents this player's personal completion status for the Activity under a
Milestone, if the activity has trackable completion and progress information. (
most activities won't, or the concept won't apply. For instance, it makes sense
to talk about a tier of a raid as being Completed or having progress, but it
doesn't make sense to talk about a Crucible Playlist in those terms.
Milestones can have associated activities which provide additional information
about the context, challenges, modifiers, state etc... related to this Milestone. [...]
Represents whatever information we can return about an explicit phase in an
activity. In the future, I hope we'll have more than just "guh, you done gone
and did something," but for the forseeable future that's all we've got. I'm
making it more than just a list of booleans out of that overly-optimistic hope.
Represents localized, extended content related to Milestones. This is
intentionally returned by a separate endpoint and not with Character-level
Milestone data because we do not put localized data into standard Destiny
responses, both for brevity of response and for caching purposes. If you really
need this data, hit the Milestone Content endpoint.
Part of our dynamic, localized Milestone content is arbitrary categories of
items. These are built in our content management system, and thus aren't the
same as programmatically generated rewards.
Any data we need to figure out whether this Quest Item is the currently active
one for the conceptual Milestone. Even just typing this description, I already
regret it.
A subclass of DestinyItemQuantity, that provides not just the item and its
quantity but also information that BNet can - at some point - use internally to
provide more robust runtime information about the item's qualities. [...]
If rewards are given in a quest - as opposed to overall in the entire Milestone -
there's way less to track. We're going to simplify this contract as a result.
However, this also gives us the opportunity to potentially put more than just
item information into the reward data if we're able to mine it out in the future.
Remember this if you come back and ask "why are quest reward items nested
inside of their own class?"
If the Milestone or a component has vendors whose inventories could/should be
displayed that are relevant to it, this will return the vendor in question. [...]
This is a bit of an odd duck. Apparently, if talent nodes steps have this data,
the game will go through on step activation and alter the first Socket it finds
on the item that has a type matching the given socket type, inserting the
indicated plug item.
This defines the properties of a "Talent Node Step". When you see a talent node
in game, the actual visible properties that you see (its icon, description, the
perks and stats it provides) are not provided by the Node itself, but rather by
the currently active Step on the node. [...]
Okay, so Activities (DestinyActivityDefinition) take place in Destinations (
DestinyDestinationDefinition). Destinations are part of larger locations known
as Places (you're reading its documentation right now). [...]
Sometimes, we have large sets of reusable plugs that are defined identically and
thus can (and in some cases, are so large that they must) be shared across the
places where they are used. These are the definitions for those reusable sets of
plugs. [...]
Sockets may refer to a "Plug Set": a set of reusable plugs that may be shared
across multiple sockets (or even, in theory, multiple sockets over multiple
items). [...]
As/if presentation nodes begin to host more entities as children, these lists
will be added to. One list property exists per type of entity that can be
treated as a child of this presentation node, and each holds the identifier of
the entity and any associated information needed to display the UI for that
entity (if anything)
Presentation nodes can be restricted by various requirements. This defines the
rules of those requirements, and the message(s) to be shown if these
requirements aren't met.
The set of progression-related information that applies at a Profile-wide level
for your Destiny experience. This differs from the Jimi Hendrix Experience
because there's less guitars on fire. Yet. #spoileralert? [...]
Information about a current character's status with a Progression. A progression
is a value that can increase with activity and has levels. Think Character Level
and Reputation Levels. Combine this "live" data with the related
DestinyProgressionDefinition for a full picture of the Progression.
These are pre-constructed collections of data that can be used to determine the
Level Requirement for an item given a Progression to be tested (such as the
Character's level). [...]
Inventory Items can reward progression when actions are performed on them. A
common example of this in Destiny 1 was Bounties, which would reward Experience
on your Character and the like when you completed the bounty. [...]
Represents the public-facing status of an activity: any data about what is
currently active in the Activity, regardless of an individual character's
progress in it.
Information about milestones, presented in a character state-agnostic manner.
Combine this data with DestinyMilestoneDefinition to get a full picture of the
milestone, which is basically a checklist of things to do in the game. Think of
this as GetPublicAdvisors 3.0, for those who used the Destiny 1 API.
A milestone may have one or more conceptual Activities associated with it, and
each of those conceptual activities could have a variety of variants, modes,
tiers, what-have-you. Our attempts to determine what qualifies as a conceptual
activity are, unfortunately, janky. So if you see missing modes or modes that
don't seem appropriate to you, let us know and I'll buy you a beer if we ever
meet up in person.
Data regarding the progress of a Quest for a specific character. Quests are
composed of multiple steps, each with potentially multiple objectives: this
QuestStatus will return Objective data for the currently active step in this
quest.
In Destiny, "Races" are really more like "Species". Sort of. I mean, are the
Awoken a separate species from humans? I'm not sure. But either way, they're
defined here. You'll see Exo, Awoken, and Human as examples of these Species.
Players will choose one for their character.
If you want to report a player causing trouble in a game, this request will let
you report that player and the specific PGCR in which the trouble was caused,
along with why. [...]
If you're going to report someone for a Terms of Service violation, you need to
choose a category and reason for the report. This definition holds both the
categories and the reasons within those categories, for simplicity and my own
laziness' sake. [...]
A specific reason for being banned. Only accessible under the related category (
DestinyReportReasonCategoryDefinition) under which it is shown. Note that this
means that report reasons' reasonHash are not globally unique: and indeed,
entries like "Other" are defined under most categories for example.
Represents a heuristically-determined "item source" according to Bungie.net.
These item sources are non-canonical: we apply a combination of special
configuration and often-fragile heuristics to attempt to discern whether an item
should be part of a given "source," but we have known cases of false positives
and negatives due to our imperfect heuristics. [...]
All Sockets have a "Type": a set of common properties that determine when the
socket allows Plugs to be inserted, what Categories of Plugs can be inserted,
and whether the socket is even visible at all given the current game/character/
account state. [...]
Describes the way that an Item Stat (see DestinyStatDefinition) is transformed
using the DestinyStatGroupDefinition related to that item. See both of the
aforementioned definitions for more information about the stages of stat
transformation. [...]
When an inventory item (DestinyInventoryItemDefinition) has Stats (such as
Attack Power), the item will refer to a Stat Group. This definition enumerates
the properties used to transform the item's "Investment" stats into "Display"
stats. [...]
Stat Groups (DestinyStatGroupDefinition) has the ability to override the
localized text associated with stats that are to be shown on the items with
which they are associated. [...]
As of Destiny 2, nodes can exist as part of "Exclusive Groups". These differ
from exclusive sets in that, within the group, many nodes can be activated. But
the act of activating any node in the group will cause "opposing" nodes (nodes
in groups that are not allowed to be activated at the same time as this group)
to deactivate.
I see you've come to find out more about Talent Nodes. I'm so sorry. Talent
Nodes are the conceptual, visual nodes that appear on Talent Grids. Talent Grids,
in Destiny 1, were found on almost every instanced item: they had Nodes that
could be activated to change the properties of the item. In Destiny 2, Talent
Grids only exist for Builds/Subclasses, and while the basic concept is the same (
Nodes can be activated once you've gained sufficient Experience on the Item, and
provide effects), there are some new concepts from Destiny 1. Examine
DestinyTalentGridDefinition and its subordinates for more information. This is
the "Live" information for the current status of a Talent Node on a specific
item. Talent Nodes have many Steps, but only one can be active at any one time:
and it is the Step that determines both the visual and the game state-changing
properties that the Node provides. Examine this and
DestinyTalentNodeStepDefinition carefully. IMPORTANT NOTE Talent Nodes are,
unfortunately, Content Version DEPENDENT. Though they refer to hashes for Nodes
and Steps, those hashes are not guaranteed to be immutable across content
versions. This is a source of great exasperation for me, but as a result anyone
using Talent Grid data must ensure that the content version of their static
content matches that of the server responses before showing or making decisions
based on talent grid data.
Talent Grids on items have Nodes. These nodes have positions in the talent grid'
s UI, and contain "Steps" (DestinyTalentNodeStepDefinition), one of whom will be
the "Current" step. [...]
This property has some history. A talent grid can provide stats on both the item
it's related to and the character equipping the item. This returns data about
those stat bonuses.
These properties are an attempt to categorize talent node steps by certain
common properties. See the related enumerations for the type of properties being
categorized.
Unlock Flags are small bits (literally, a bit, as in a boolean value) that the
game server uses for an extremely wide range of state checks, progress storage,
and other interesting tidbits of information.
Where the sausage gets made. Unlock Expressions are the foundation of the game's
gating mechanics and investment-related restrictions. They can test Unlock Flags
and Unlock Values for certain states, using a sufficient amount of logical
operators such that unlock expressions are effectively Turing complete. [...]
An Unlock Value is an internal integer value, stored on the server and used in a
variety of ways, most frequently for the gating/requirement checks that the game
performs across all of its main features. They can also be used as the storage
data for mapped Progressions, Objectives, and other features that require
storage of variable numeric values.
If a vendor can ever end up performing actions, these are the properties that
will be related to those actions. I'm not going to bother documenting this yet,
as it is unused and unclear if it will ever be used... but in case it is ever
populated and someone finds it useful, it is defined here.
A vendor can have many categories of items that they sell. This component will
return the category information for available items, as well as the index into
those items in the user's sale item list. [...]
This component returns references to all of the Vendors in the response, grouped
by categorizations that Bungie has deemed to be interesting, in the order in
which both the groups and the vendors within that group should be rendered.
BNet attempts to group vendors into similar collections. These groups aren't
technically game canonical, but they are helpful for filtering vendors or
showing them organized into a clean view on a webpage or app. [...]
A Vendor Interaction is a dialog shown by the vendor other than sale items or
transfer screens. The vendor is showing you something, and asking you to reply
to it by choosing an option or reward.
Compare this sackType to the sack identifier in the
DestinyInventoryItemDefinition.vendorSackType property of items. If they match,
show this sack with this interaction.
The definition for an "inventory flyout": a UI screen where we show you part of
an otherwise hidden vendor inventory: like the Vault inventory buckets.
In addition to item quantity information for vendor prices, this also has any
optional information that may exist about how the item's quantity can be
modified. (unfortunately not information that is able to be read outside of the
BNet servers, but it's there)
If a character purchased an item that is refundable, a Vendor Receipt will be
created on the user's Destiny Profile. These expire after a configurable period
of time, but until then can be used to get refunds on items. BNet does not
provide the ability to refund a purchase yet, but you know.
For now, this isn't used for much: it's a record of the recent refundable
purchases that the user has made. In the future, it could be used for providing
refunds/buyback via the API. Wouldn't that be fun?
Request this component if you want the details about an item being sold in
relation to the character making the request: whether the character can buy it,
whether they can afford it, and other data related to purchasing the item. [...]
