Improving inventory inefficiencies
-
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.
-
-
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. -
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 anAwardMultipleUserItems()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.
Paul.
-
Hello.
Bundles are a necessary feature. We plan to fully utilize them soon.
I lack information about bundles.
How do you handle items already owned?
(The expected behavior is that if one quantity-limited item already exists, it should be skipped, and if it's stock-based, one should be added.)AwardMultipleUserItems is correct.
We need to dynamically assign items based on data released in the itemCatalog.
We're solving this with a script, but we're using it in a scenario where updated items are randomly assigned.
The problem is that the number of randomly assigned items is around 100.
This represents an inefficiency in the number of script calls and backend processing.
Please include this in your roadmapThank you.
-
Bundles are described in our release notes here - https://updates.braincloudservers.com/braincloud-5.9-is-live-23Q66A
Randomly assigning 100 items? (Gotta say that sounds like a lot). That said - we are adding it to our roadmap.
