Idea

brendan avatar image
brendan suggested

GrantItemsToUser should not create duplicate nonstackable items

10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

6 Comments

·
brendan avatar image
brendan commented

lango
started a topic on Mon, 24 August 2015 at 8:14 PM

If a play already owns item X, and that item is not stackable, calling GrantItemsToUser still creates a duplicate of the item in the user's inventory.

I'd like to suggest that the API checks for nonstackable items and returns a new error code if the server tries to grant a duplicate of an already owned item.

Example: NonStackableItemAlreadyOwned

This may also be the case with purchases as well, but I haven't check.


7 Comments
Brendan Vanous said on Tue, 25 August 2015 at 12:11 AM

Unfortunately, that would prevent titles which specifically do allow players to have more than one of a given item from functioning correctly. If items are meant to be unique for players in your title, I would recommend not presenting the player with the option to purchase the item more than once.

Brendan


lango said on Tue, 25 August 2015 at 12:20 AM

Hi Brendan,

Thank you for the reply. Maybe I'm confused by the Stackable checkbox in the inventory section of Game Manager.

My thinking is that if an item is stackable, you can own multiple instances of the same item.

If an item is not stackable, it is "unique" and a player can only own one instance at a time.

If that's not the way it works, can I put in a feature request for items to have a "unique" characteristic?


Brendan Vanous said on Thu, 27 August 2015 at 2:06 AM

I would actually say it's neither. When we first launched our service, we didn't have the stackable flag. So, there are existing titles which allowed players to have multiples of an item without that flag.

It is true that the most efficient way to use the catalog is to define items where the player can have more than one as stackable though, and I would encourage any new title developer in our service to use it that way.

Brendan


lango said on Thu, 27 August 2015 at 4:00 AM

To illustrate my problem, I've created some sample items inside a catolog. These items are not "stackable." When a new user registers, I use a cloud script to grant these items to the player. However, if I call GrantItemsToUser multiple times, there are multiple instances of the items created in the player's inventory. Of course I can do checks myself, but it makes more sense for the server to validate if the purchase/grant passes a stackable/unique parameter.


Brendan Vanous said on Thu, 27 August 2015 at 9:11 AM

Sorry, let me rephrase: The existing behavior of stackable, and titles being able to have non-stackable items which the player can have more than one of, is as intended. We try very hard not to limit the way titles can use our functionality, and some titles do want to be able to do this. So the initial request - that non-stackable items cannot be added to a player's inventory more than once - would restrict titles, as well as break functionality for existing titles in the wild.

Titles can check the player inventory and not show items which the player already has in a purchase interface. It sounds like you're concerned about a title bug which, despite a check like that, adds an item more than once unintentionally. So a separate "don't add more than one" / "unique" flag would be the feature request, I believe. I'm adding that to the backlog, so that it is tracked appropriately.


lango said on Thu, 27 August 2015 at 3:44 PM

Yes, I am asking for a unique item flag (I'm still confused by what stackable means). This way if a player tries to buy / grant / trade a duplicate of a unique item, it will throw an error. Thanks, Brendan.


Brendan Vanous said on Thu, 27 August 2015 at 7:16 PM

Stackable simply means that the item in question stacks when more of it is added to the user's inventory. The most common usage is for collectible/trading card games, where the player could have many copies of a specific card. Rather than have each instance of the card showing up as a distinct item (with its own instance ID), requiring the title to aggregate all of the items, they're collapsed into a single instance with a count.

Thanks for confirming - we've got the request for a "unique" flag on the backlog.

Brendan

10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

mail avatar image
mail commented

Any progress on the "unique" Flag? A function / flag that shows if this item is already owned by the user when requesting the catalog would be appreciated as well!

1 comment
10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

brendan avatar image brendan commented ·

Sorry, but until something is in active development, we really aren't able to give any estimates on availability. The issue is that as a live service, our priorities can change quickly and we wouldn't want someone to take a dependency on us for something we're not 100% sure we'll deliver when we say we will.

0 Likes 0 ·
Greg Quinn avatar image
Greg Quinn commented

@Brendan Any update on this? This would be used in almost every game where the player has a cosmetic item they can randomly be granted. Since cosmetics are usually granted once only and kept during the player lifetime. Just a unique/can only be granted once would be really helpful.

10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

t-m1 avatar image
t-m1 commented
10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Resul Volkan Ozcan avatar image
Resul Volkan Ozcan commented

We need that feature

10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Good Guy avatar image
Good Guy commented

Could people elaborate on their use-case for this? Even I voted for this, but I now better understand the system and am not sure I would want what this request is asking for. Let's review:

1. "Chair" Item without Stackable: You get 4 of them. The player inventory shows 4 identical chairs.

But maybe your game is programmed to let you customize stats (custom data, or custom tag?) on each chair, so now you can have 4 chairs each with a different attribute. Red, Green, Blue, Yellow chairs.

2. "Chair" item with Stackable checked on. You get 4 of them. The inventory shows 1 chair with 4 "uses". All 4 chairs would of course have the same custom data or custom tags. Therefore only 1 color attribute is possible. Only red for example.

So what is the feature request here? Preventing 4 chairs in scenario 1 being possible? Preventing more than one "use", as in scenario 2?

Maybe what we need is a checkbox for owned limit?

10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Write a Comment

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Your Opinion Counts

Share your great idea, or help out by voting for other people's ideas.

Related Ideas