I always get ConfigOrigin.Remote when I run in offline. I tried on mobile - the same.
I tried [1.2.3] and [1.2.4-preview.4].
Switch statements worked correctly with v1.09 for me.
private void ApplyRemoteSettings(ConfigResponse cr)
{
switch (cr.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;
[B] case ConfigOrigin.Remote: [/B]
Debug.Log("New settings loaded this session; update values accordingly.");
break;
}
}
Can you actually try to load specific values? Your case statements are empty, can you retrieve values at that point and confirm that remote values or cached values are used? Provide the output of your Debug.Log statements and the server-side values and the last cached expected value.
Yes, in online mode all values are retried and cached. Also all values that I change in web site are also changed in the next reload of game.
But, if I delete the cache file (json) manually, simulating the android clean app cache option and close internet connection on mobile, then value that I get is 0 as default static variable assignment in cs. (if I had set it to 0.5f then I will got 0.5f)
The problem is that even in offline mode and with existing cached json file the requestOrigin return ConfigOrigin.Remote instead of ConfigOrigin.Default BUT whatever read from json cached file and return json’s cached values.
Please provide specific steps to reproduce, sorry I’m not quite following. Please provide your Debug.Log output and the corresponding code so I can try to reproduce here, as requested. It sounds like what you are saying that it’s properly reading the local cache after a previous successful connection, but it’s triggering/returning the wrong requestOrigin (Remote vs Cached). You are also deleting files. Can you elaborate on the “android clean app cache option”?
I suspect if you are deleting the cache between sessions or similar, it would show as Remote. What would your expectation be? It’s not Default because it expects Cached, it’s not Cached because you deleted it.
With deleted cache file it shows Remote in offline mode.
2)Why it is expects cache if cache file do not exists ? Maybe some checks in code will fix this bug.
3)With cache file and offline mode it still shown Remote instead of Cached, but bring values from cached file.
If I manually change values in RemoteConfig.json I will see new values in Console but in ConfigOrigin.Remote case statement not in ConfigOrigin.Cached.
I tried to move initialization code from Awake to Start but the same.
It is not big problem, this case it is rare to occur.
It would not be a bug if you’ve deleted a resource, but a feature request. It should not say Cached if Cached is not available. Again, what is your expectation if the user does this? What switch statement would you like to add, since your use-case doesn’t seem to fit into the current ones. If it is expecting Cached but someone deleted the cache, would you expect it to go back to Default, or a new value.
I expect to go to Default in this case.
If cache file do not exists and no internet connection exists this meas that I have to provide default values to user.
But I get 0 in all variables in this case because no cache exists and it is offline and system still return Remote…
Why Default then exists in switch if never used ?
As I mentioned before only version 1.0.9 falls into Default. All other versions return Remote.
Sorry I don’t follow. Default is used if there is no Internet connection and there hasn’t been a previous session. That’s not the case here. You’ve deleted files. Returning Default in this case would be difficult to support for you. Users would call into you complaining they lost progress or similar. You wouldn’t know if they are first time users or just deleted their cache somehow, you haven’t specified the process.
Just in case someone else ends up here, don’t waste your time with ConfigOrigin. ConfigOrigin is always ConfigOrigin.Remote because ConfigOrigin.Default and ConfigOrigin.Cached are never used in the actual Remote Config package’s code. Sure they’re are in the example code from who knows what version but if you actually search the code in com.unity.remote-config@2.1.2, & com.unity.remote-config-runtime@2.1.2, I’m on version 2.1.2 obviously, you will NOT find a single occurrence of ConfigOrigin.Default or ConfigOrigin.Cached in the actual code for the package. You will however find that configResponse orgin is set to ConfigOrigin.Remote on line 368 of ConfigManagerImpl.cs and then passed straight into the configResponse as is in line 124 of the same file. Someone at Unity seriously needs to update the documentation so people don’t waste hours of their lives figuring this out like I just did.
You are referring to an older version of Remote Config, the latest is 3.0.0-pre.9 . And if your claims are true, we wouldn’t update the documentation, we would fix the code!
Actually, it might be better to get rid of ConfigOrigin completely. I found that since the class which uses the Remote Config data should validate and save a copy of the data it gets from Remote Config anyway, whether the data is from online or cache made no difference in the end. The code I have working now does not use ConfigOrigin and works just fine, better even, since my code has to take responsibility for keeping track of data it itself uses when it’s available. Appreciate the features but I think in this case simplicity would be better.
Many developers are already using ConfigOrigin so removing it would break their code. In your case it sounds like you don’t need the feature so you can safely ignore it. I will go ahead and lock this thread now.