Improving inventory inefficiencies

noah

Hello.

I'd like to ask about some inefficiencies in the user inventory.

Item rewards should be called individually, not in bulk.
To find items based on their 'defId' within the inventory, a full search is required.

For itemCatalogs, which can only hold one item, we need to check if the item exists in the user's inventory before issuing the reward.
The problem is that it only supports itemId-based verification.

Furthermore, since there's no bulk-based reward payment system, rewards must be paid out individually. However, setting up approximately 100 to 200 items initially...

results in inefficient code.

JasonL

Just a heads-up, our team is working on this bulk userItem feature.

noah

hi, @JasonL any update?

JasonL

We are deploying brainCloud v5.9 today, which includes a new bulk userItem feature that addresses the inefficiencies you mentioned about the multiple item rewards. Please give it a try later today and let us know if it resolves your use case.

noah

hi. @JasonL
This is somewhat different from what I had in mind.
While bundling and using it is a viable option,
it differs somewhat from the goal of "dynamically distributing a single item at once."
Bundles require pre-composition and require version control. Furthermore, the actual disbursement only occurs after the bundle is opened.
A function like AwardUserItem (multi defIds) is required.

JasonL

Thank you for the feedback. We’ll take a look and follow up if needed.

noah

Will there be an update?
We are still inefficiently paying out one item repeatedly through AwardUserItem.

Paul Winterhalder

So @noah ,

I guess we misunderstood your use case. By the way you were describing things, we were envisioning a scenario where a user avatar is created, and they need to have an initial set of items - i.e., a cheap sword, a cheap shield, worn leather armor, worn boots, etc. Thus, we thought allowing you to add that to a bundle (where maybe you'd have a different bundle per character class) would make sense.

But I guess that's not what you are getting at? From your message:

It differs somewhat from the goal of "dynamically distributing a single item at once."

I mean - if it's a quantity of a SINGLE item as you say - then our existing AwardUserItem() call does allow you to specify a quantity. That said, I suspect you mistyped and meant to say "dynamically distributing MULTIPLE items at once" - which, as you say, would require an AwardMultipleUserItems() call.

Anyway, we can queue up an AwardMultipleUserItems() call on the roadmap - but we're doing heavy lifting on new features for 6.0 right now - and this is easily handled via a custom script (and remember, calls from scripts are just 1/2 API count each, so it's more efficient that way too) - so it won't be top priority at this point.

So - in summary - I can't promise this will be in the next release. Never say never (sometimes the devs fit extra stuff in once the main features are complete) - but I'd say unlikely for 6.0 - more likely for 6.1 or 6.2.

But as I noted - easily handled via a script, right? Unless I'm missing something?

Paul.