question

dragonfoundry avatar image
dragonfoundry asked

Stackable & Consumable by time

If I set an item as Stackable, and Consumable by time (say, 30 days), and then the item times out, and then I grant the user another one of those items, the new item shows up as Revoked. It should show up in inventory, and stay there until it times out.

I can work around this by not setting the item to stackable, but it's definitely not expected behaviour.

Player Inventory
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 answered

We actually have an open work item on this internally, but let me confirm the behavior you expect, based on our internal write-up:

Each inventory item instance has exactly one usage period. If intent is that each individual instance of the item added should expire at a distinct time, then the item should not be stackable. Our expectation is that if an item is set as both consumable by time (usage period) and stackable, then the item expiration should be incremented by the usage period whenever an item is added to the stack. So, if the item expires after 1 hour, and you add 3 to the stack, the expiration for the stack should be 3 hours later than it was before they were added.

Does that sound like what you have in mind?

10 comments
10 |1200

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

dragonfoundry avatar image dragonfoundry commented ·

Yes. Plus, if the item has been consumed, it's reset to unconsumed, with its new usage period set.

There's some unhappy outcomes with adding containers (but not bundles) to that mix, but I don't think you can avoid having something go wrong there.

0 Likes 0 ·
brendan avatar image brendan dragonfoundry commented ·

What are you seeing with Containers?

0 Likes 0 ·
dragonfoundry avatar image dragonfoundry commented ·

No problems - we don't use that combo

if an item is a container, it should open on consume, via timeout. Adding another stack to it when it's timed could result in opening one when its new time runs out, not two

0 Likes 0 ·
brendan avatar image brendan dragonfoundry commented ·

Actually, a container is only opened via UnlockContainer. It is not opened on a timeout. I would only use time expiration on a container if you wanted it to be something that the player either opens within a set time, or loses. When the container is opened, that's when its remaining uses is decremented.

0 Likes 0 ·
dragonfoundry avatar image dragonfoundry commented ·

This is now a bigger bug - it seems Stackable items that are consumable (not by time) are also affected, If the user has more than one stack of the item somehow.

I just granted a player (3B7B06BDCE7F9172) an item (101102) that he had three stackable instances of (with 1, 1, and 7 stacks). The item grant revoked the stacks with 1 object on them (the 7-stack was the oldest stack, and that one remained). The granted item was also revoked! Luckily, further grants do work correctly here, so I was able to fix the issue for the player.

This isn't expected behaviour, and it'll cause a big customer service issue

0 Likes 0 ·
brendan avatar image brendan dragonfoundry commented ·

Sorry, but can you give me your specific repro steps, including the catalog setup? It is the case that if you set up an item as not stackable, add it to players, and then later change the item to be stackable, you'll have an issue where you need to do some additional work (in Cloud Script) to clean up the non-stackable instances. It is also the case that when items are stacked, all but the "primary" stack are revoked, with the count for each of the revoked items being added to the "primary", but I'm not able to reproduce a case where stacking results in all instances being revoked.

0 Likes 0 ·
dragonfoundry avatar image dragonfoundry commented ·

This is definitely just with regular stackable items - the oldest item has stacks, so it must have been stackable. The trick to reproing this is getting a player two instances of a stackable item The best way to do that is to try to make multiple item grants in parallel. Once you've done that, granting another of those items will revoke the granted ones and fail to add to the original stack

0 Likes 0 ·
brendan avatar image brendan dragonfoundry commented ·

Ah, okay. The issue where a player winds up with two stacks for one stackable ItemId is indeed a corner case which you can force that way. It's a known issue, and we have some inventory refactoring work we've been doing that'll resolve it. We'll get that live as soon as we can, but it's likely going to be a few weeks yet. However, the only way I know of right now to make it happen is what you describe - multiple simultaneous requests, which you should avoid as much as possible. Are you seeing this show up any other way?

0 Likes 0 ·
dragonfoundry avatar image dragonfoundry commented ·

Pretty sure this was multiple simultaneous (or one giant one that messed up)

0 Likes 0 ·
brendan avatar image brendan dragonfoundry commented ·

[Updating the status]

There are two things described in this thread:

1. Adding a stackable with a consumption time wasn't adding a new stack of that item after the old stack expired. This is fixed.

2. A title that issues multiple calls to add the same stackable inventory item simultaneously could wind up with the player having more than one stack of the item. This will be fixed in an upcoming release - and since the code for this is largely done, I can say that'll be within a few weeks, at most (it does require extensive testing before we push it to the live service). Please be aware that across the board, titles should be waiting on responses from the service before issuing new responses, so this should largely be a non-issue for titles.

0 Likes 0 ·
dragonfoundry avatar image
dragonfoundry answered

I've tested this, and I don't see it behaving the way we expect, at least in the Game Manager display. (1) Grant one instance of a stackable item, with one remaining use, and an Expiry of June 1st (all this is expected). (2) Grant a second instance. I now have an item with 2 remaining uses, but the Expiry is still listed as June 1st. I'd expect 2 uses, and July 2nd.

2 comments
10 |1200

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

dragonfoundry avatar image dragonfoundry commented ·

Tested with 2 minute timeouts. The object does indeed disappear after the first 2 minutes is up, no matter how many stacks were purchased

0 Likes 0 ·
brendan avatar image brendan dragonfoundry commented ·

If you want the expiration time to increment by the usage period each time you add another, you'll want to set the Usage Period Group to something non-null. Anytime an item is added with the same Usage Period Group as an existing item, its usage period will then be added.

0 Likes 0 ·

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

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