Hello,
Is there a Cloud Code equivalent to “GetInventoryItem” ? I can use
InventoryItemDefinition definition = EconomyService.Instance.Configuration.GetInventoryItem(“MY_KEY”); from the client side, but I would like to do something with the custom data from Cloud Code that the player doesn’t need to have access to, and then send the result back. I don’t see any way to get resources from the economy via Cloud Code.
I don’t think it’s possible currently. We’ll need a feature request for this.
Yes, it is part of the Economy’s Inventory API:
Example code for accessing player inventory items data:
const playerInventoryResult = await inventory.getPlayerInventory({ projectId, playerId });
//data is contained in the array
let arrayResults = playerInventoryResult.data.results
If you’re looking for access all items, and not just the inventory of a specific player, you’ll have to get that via Configuration API. That will return all items and overrides available to the logged in player:
Example code for accessing all items returned:
const configResults = await configuration.getPlayerConfiguration({ projectId, playerId });
//then your results are in this array data
let arrayResults = configResults.data.results;
Be sure to include the libraries and set them up appropriately, this is at the top of your file:
const { InventoryApi } = require(" @ -services/economy-2.4");
const { ConfigurationApi } = require(" @ -services/economy-2.4");
And initialized at the top of your entry point function
module.exports = async ({ params, context, logger }) => {
// Log an info message with the parameters provided to the script and the invocation context
logger.info("Script parameters: " + JSON.stringify(params));
const { projectId, playerId, environmentId, accessToken } = context;
const remoteConfig = new SettingsApi({ accessToken });
const inventory = new InventoryApi({ accessToken });
This works even if the player doesn’t own the item?
Yes, there’s confusing terminology with the API call getPlayerConfiguration. It reads like the player has to own something, and they do, but they just “own” the economy configuration that applies to them. This call will return the configuration that is relevant to them: all resources, like virtual purchases, currencies, ownable inventory items, and real money purchase (I assume, as I don’t use them).
This seems to be a very expensive call if it has to get all the resources. What if there’s thousands of items? It’s not much different than my current method of saving the data in RemoteConfig. A call to RemoteConfig is free vs a possible costly API call to economy.
I ended up getting it from the public url and axios:
let url = https://economy.services.api.unity.com/v2/projects/${context.projectId}/players/${context.playerId}/config/resources;
Not sure if that is any less expensive though.
I still think we need to be able to get specific items.
A use case is to check if a player has reached the required level to buy an item from a shop. Loading every single item in the system each time a player makes a purchase seem very wasteful and not very practical.
The documentation explains how to get a single item, my example code is for how I use the API.
If you want a single item and know its id, you can pass those it to the API to limit results.
You’ll have to pass an InventoryApiGetPlayerInventoryRequest object into the getPlayerInventory API, which would be a list of ids you want returned.
We’re not asking about the player’s inventory item. We need the item definition that a player does not own. We need the custom data from the item. If the player is trying to buy this item, it means they don’t currently own it.
Thanks for the clarification!
Okay, here’s what I do for that:
Cache the results of the config retrieval in cloudsave (would be better if I could cache the lookup in config, so it wasn’t per-user, but I don’t currently see that API).
This will save you some cycles in subsequent calls to this script for as long as that cache is valid, usually - a config look up can be anywhere from 650-1400ms for me @ 450 inventory items for purchase. Before caching, I convert it to a dictionary with entries mapped to id.
After that, use the store cache as an id-based comparison against the player inventory to determine if purchase is required.
The script that I have to do all this, WITHOUT caching store data takes about 1500ms. However, it does CONSIDERABLY more than just hitting the config API. It parses and operates on customData, checks player currency balances, inventory, games state to apply any properties gained by purchases, etc.
If anyone really needs an example of it, I can probably clean it up and remove any game-specific info then post it.
Hello. I just came across this topic and its solutions.
Currently my scenario is this:
I have a cloudScript that lists the player’s inventory items and while doing this, he needs to know the type of item he is looking at. There is custom data for each item in the store. It is a string that I made if the item is of type (Stage, Character, Weapon). Etc…
The problem is that through the player’s inventory this item does not show the customData. InstanceData only. But the item’s instanceData is null, because he acquired it through a purchase and not through a CloudScript. Here I am now.
I’m in economy 2.4
1 - Is it possible to make every purchased item go to the player’s inventory with the customData instantiated? Because currently in the conventional way, customData is not instantiated!
2 - If 1 is not possible, have you already implemented the search for a single item through ConfigApi?
3 - If nothing is possible, how do I cache this in the cloud?
Currently the way I found is to look at the initials of the item name to know the type.
But this way I have to guarantee that every new item registered in the store has initials indicating the type. It’s quite strange to do this, in my opinion! I believe that the best and simplest way would be for customData to be instantiated automatically when it goes to the inventory. The default data would be the values already registered in json! I don’t understand why this isn’t standard!