Started to play with Remote Config today…
These two structs (userAttributes and appAttributes) are required by FetchConfigs method.
However, I’m confused on what is suppose to be in each of these structs.
Some questions…
.AppConfig is related to whatever is in ConfigManager.appConfig?
.userAttributes have a preview in Dashboard or somewhere else?
.What sort of attributes can come in that userAttribute?
.Each player have one userAttribute?
.Each player have one AppAttribute?
.How can I clean my cached result?
AppConfig is related to what’s in ConfigManager.appConfig. But AppAttributes and UserAttributes are used by the conditions in remote config rules. They’re for you to create, if you don’t need them, in the newer packages, you should be able to pass in null.
Any public serializable field you put in your attributes structs can be used in rules for segmentation.
Each request can have one user and app attribute struct, you could pass different structs into each request. There currently isn’t a limit on the number of attributes.
There’s no way to currently clear the cache result, other than looking through the package source and removing the file where we write the cached results to. Out of curiosity, what’s your use case for wanting to clear the cache?
Hope those help, let me know if you have more questions!
Thanks for the answer @rambod
I’m probably missing something but…
In short terms, I want to force the usage of a remote data for debugging and clear cache could be helpful in that case. Also, I want to be 100% sure that any value I got is not from a cached result but from the remote data I’m tweaking. ConfigResponse.requestOrigin helps on that but once you notice that you’re using the cached version, there’s not much to do but to restart Unity or investigate the package source to find out the cached file as you’ve mentioned.
Regarding to the previous questions…
How to preview userAttribute data in server?
Hi @YJack !
I am not 100% sure if I understand the clear cache use case so please correct me if I did not get it right,
but one way to ensure you got the remote data is to check for ConfigOrigin.Remote in configResponse after FetchConfigs(), and then apply your overwrites.
That would overwrite your cache file with new remote values, so there is no need to restart Unity or investigate the package source.
Of course, you can call FetchConfigs more than once within your session, if you have need for it.
From the docs:
// Retrieve and apply the current key-value pairs from the service on Awake:
void Awake () {
// Add a listener to apply settings when successfully retrieved:
ConfigManager.FetchCompleted += ApplyRemoteSettings;
// Set the user’s unique ID:
ConfigManager.SetCustomUserID("some-user-id");
// Fetch configuration setting from the remote service:
ConfigManager.FetchConfigs(new userAttributes(), new appAttributes());
}
void ApplyRemoteSettings (ConfigResponse configResponse) {
// Conditionally update settings, depending on the response's origin:
switch (configResponse.requestOrigin) {
case ConfigOrigin.Default:
Debug.Log ("No settings loaded this session; using default values.");
break;
case ConfigOrigin.Cached:
Debug.Log ("No settings loaded this session; using cached values from a previous session.");
break;
case ConfigOrigin.Remote:
Debug.Log ("New settings loaded this session; update values accordingly.");
enemyHealth = ConfigManager.appConfig.GetInt ("enemyHealth");
assignmentId = ConfigManager.appConfig.assignmentID;
break;
}
}
As for this part, it’s not something we support today, but if you could give me some more details on what you’d like to see and do with that, I can get it documented as a feature request on our end.
Again. I’m pretty new on that so please, let me know if I’m missing something,
I’ll give some examples from the top of my mind…
So I’ve added some userAttribute to my player… let’s say… “XP”.
I can see the following circunstancies happening:
. I’m debugging this feature want to check if the right set/get “XP” value worked as expected consulting that value into the remote config based on my playerID.
. I decide to rename or remove this “XP” value.
. I decide to manually change that value for a single player.
. I decide to change all “XP” value for all my players.
I’m trying to better understand the use case you have above. Is that you want a key “XP” in Remote Config that you want to send down to players? Or do you want players to receive different values for keys based on how much XP they have?
Perfect, okay, so for that, here’s what you’d probably want:
Add a variable to your userAttributes struct, like “totalXp” and set that before fetching your config.
In your config, set up whatever variables you’d want changed based on the XP of the player, and implement the runtime Remote Config code in your project.
You can create rules, where in the condition you can do things like “user.totalXp > 0 && user.totalXp <= 1000” let’s say. This rule will now go into effect for users whose xp is between 0 and 1000. In the rule, you can specify your override values that you’d like this user group to receive.
Repeat the above steps with as many rules as you need for your user groups.
Hopefully this helps, but let me know if anything is unclear!
I can not speak for YJack’s needs, but one clear use case would be to provide auto-complete when defining rules using conditions for user.* and app.* in the rule editor.
This please. Allowing to TYPE rules for designers is prone to human error. TYPO in variable name, and the rule doesn’t work. No information or warning until you notice that it doesn’t work in the game.