bungie-net-core
Version:
An easy way to interact with the Bungie.net API
122 lines (121 loc) • 6.07 kB
TypeScript
/**
* Bungie.Net API
* These endpoints constitute the functionality exposed by Bungie.net, both for more traditional website functionality and for connectivity to Bungie video games and their related functionality.
*
* Contact: support@bungie.com
*
* NOTE: This class is auto generated by the bungie-net-core code generator program
* Repository: {@link https://github.com/owens1127/bungie-net-core}
* Do not edit these files manually.
*/
import { VendorItemStatus } from '../../VendorItemStatus';
import { DestinyUnlockStatus } from '../../DestinyUnlockStatus';
import { DestinyVendorItemState } from '../../DestinyVendorItemState';
import { DestinyItemQuantity } from '../../DestinyItemQuantity';
/**
* 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.
*
* Note that if you want instance, stats, etc... data for the item, you'll have to
* request additional components such as ItemInstances, ItemPerks etc... and
* acquire them from the DestinyVendorResponse's "items" property.
* @see {@link https://bungie-net.github.io/#/components/schemas/Destiny.Entities.Vendors.DestinyVendorSaleItemComponent}
*/
export interface DestinyVendorSaleItemComponent {
/**
* A flag indicating whether the requesting character can buy the item, and if not
* the reasons why the character can't buy it. This enum represents a set of flags -
* use bitwise operators to check which of these match your value.
*/
readonly saleStatus: VendorItemStatus;
/**
* If you can't buy the item due to a complex character state, these will be hashes
* for DestinyUnlockDefinitions that you can check to see messages regarding the
* failure (if the unlocks have human readable information: it is not guaranteed
* that Unlocks will have human readable strings, and your application will have to
* handle that)
*
* Prefer using failureIndexes instead. These are provided for informational
* purposes, but have largely been supplanted by failureIndexes. Mapped to
* DestinyUnlockDefinition in the manifest.
*/
readonly requiredUnlocks: number[];
/**
* If any complex unlock states are checked in determining purchasability, these
* will be returned here along with the status of the unlock check.
*
* Prefer using failureIndexes instead. These are provided for informational
* purposes, but have largely been supplanted by failureIndexes.
*/
readonly unlockStatuses: DestinyUnlockStatus[];
/**
* Indexes in to the "failureStrings" lookup table in DestinyVendorDefinition for
* the given Vendor. Gives some more reliable failure information for why you can't
* purchase an item.
*
* It is preferred to use these over requiredUnlocks and unlockStatuses: the latter
* are provided mostly in case someone can do something interesting with it that I
* didn't anticipate.
*/
readonly failureIndexes: number[];
/**
* A flags enumeration value representing the current state of any "state modifiers"
* on the item being sold. These are meant to correspond with some sort of visual
* indicator as to the augmentation: for instance, if an item is on sale or if you
* already own the item in question.
*
* Determining how you want to represent these in your own app (or if you even want
* to) is an exercise left for the reader. This enum represents a set of flags -
* use bitwise operators to check which of these match your value.
*/
readonly augments: DestinyVendorItemState;
/**
* If available, a list that describes which item values (rewards) should be shown (
* true) or hidden (false).
*/
readonly itemValueVisibility: boolean[];
/**
* The index into the DestinyVendorDefinition.itemList property. Note that this
* means Vendor data *is* Content Version dependent: make sure you have the latest
* content before you use Vendor data, or these indexes may mismatch.
*
* Most systems avoid this problem, but Vendors is one area where we are unable to
* reasonably avoid content dependency at the moment.
*/
readonly vendorItemIndex: number;
/**
* The hash of the item being sold, as a quick shortcut for looking up the
* DestinyInventoryItemDefinition of the sale item. Mapped to
* DestinyInventoryItemDefinition in the manifest.
*/
readonly itemHash: number;
/**
* If populated, this is the hash of the item whose icon (and other secondary
* styles, but *not* the human readable strings) should override whatever icons/
* styles are on the item being sold.
*
* If you don't do this, certain items whose styles are being overridden by
* socketed items - such as the "Recycle Shader" item - would show whatever their
* default icon/style is, and it wouldn't be pretty or look accurate. Mapped to
* DestinyInventoryItemDefinition in the manifest.
*/
readonly overrideStyleItemHash?: number;
/** How much of the item you'll be getting. */
readonly quantity: number;
/** A summary of the current costs of the item. */
readonly costs: DestinyItemQuantity[];
/**
* If this item has its own custom date where it may be removed from the Vendor's
* rotation, this is that date.
*
* Note that there's not actually any guarantee that it will go away: it could be
* chosen again and end up still being in the Vendor's sale items! But this is the
* next date where that test will occur, and is also the date that the game shows
* for availability on things like Bounties being sold. So it's the best we can
* give.
*/
readonly overrideNextRefreshDate?: string;
/** If true, this item can be purchased through the Bungie.net API. */
readonly apiPurchasable?: boolean;
}